Have you ever written a form with multiple steps in JavaScript and thought "this isn't very elegant"? I have. Let's take a look at how we can make our forms better with type safety and TypeScript!

Types and more types!


It's time, time for some types. We'll be making a typesafe form in TypeScript and the first thing we need for that is to figure out what a form page is. The minimum we need for a functional form with multiple steps is: a way to go to the next page, a way to go back and some way to display content for each of the pages in the form. 



Let's take a look at the definition of a page.

We are using two generic types. One for the data (DATA) and one for the page name (PAGENAME). We'll be using the DATA type to share data between the pages in the form and the PAGENAME type to uniquely identify each of our pages. 

We also have three functions. One for displaying the content (here by returning a ReactNode, but you can use any framework or no framework). Next we have two optional functions, one for going to the next page (next?) and one for going to the previous page (back?). 



At the moment everything is very generic and doesn't do us much good in making our form typesafe. But let's start fixing that with defining the structure of our form!



So what is a form? It's a collection of pages and data. Again, the data is some generic data we pass around in our form, and the pages is a collection of all pages the form contains. 



With our page and form structure defined we now need to find a way for typescript to actually check the types when we'll be creating the form. 

Creating a type with PAGENAME as keys allows us to use a union type of strings that will enforce pages to be both unique and exhaustive.


Up until now we have only defined types which aren't really related to each other. They use the same generic variable names, but so far they aren't connected. The next step is to make a function to connect all our types. We do this by creating a function that takes in Structure and returns the FormStructure.

This part is a little bit hacky, but the TypeScript compiler needs a little bit of help to figure out that PAGENAME and PAGE are the same thing in both Structure and FormStructure when we use the Object.entities function to map the data. To fix this we simply cast the types.



And that's it for setting up the types we need for a typesafe form in TypeScript!

Let's try it out

Finally done with all setup and types, we are ready to create a form with some steps and some content.


An easy to read form structure with type safety! So which part of the form is typesafe? All of it of course! All pages defined in the Pages-type are required to be unique and passed to the createForm function. If we misspell a page name or forget to include it in the form the compiler will be mad at us and remind us not to do something stupid.

Remember our optional next and back functions? They are now typed and the return value must be a valid page name (again from the Pages-type). This means that each page with functionality to go to another page must be linked to a valid existing page. Great success!

And there we have it. A typesafe (branching) form with multiple steps and shared data, with types that will help us avoid silly mistakes.






Using the structured form in action



Now that we have created a form based on the typesafe FormStructure we can start using it for navigation and displaying content. To display the content of a page we pass some data to the content function we defined in our Page type. To display navigation buttons we need to check if the page has a next or back function. 

With our three functions content, next and back we have everything we need to create to create a form with navigation. And if you need a more advanced form we can simply add more things to the PAGE type, such as a submit button, a header or a way to display the current step.




The full example code can be found over at github. Click the link below to check it out.









Typesafe forms in TypeScript

Drypp er en lavterskel podcast fra Bekk.

En liten gjeng samlet inn heftige påstander og inviterte til Drypp-innspillingskveld på Trondheimskontoret - med julebrus, godis og god stemning. Resultatet ble seks episoder med brannfakler. God lytt.

Brannfakkel - Er design nødvendig da? (Del 1 av 6)

Have you ever had some new functionality that you would like to showcase for your users? Perhaps your userbase is not the most tech-savvy and they need some guiding when new features are shipped. React Joyride let's you easily create guided tours that your users will enjoy. 

Introduction

Let's face it, your users are probably not as tech-savvy as you are. When we develop new functionality for our intended users, it can be easy to take the functionality for granted and just assume that everyone knows how the new features work. With React Joyride we can easily create guided tours for our users, and let them know about new features and how they are to be used.

Getting started

To get started, we need to install React Joyride as an dependency



We then have to setup our steps for the ride, and hook the steps up to our components. I like to create a new file for our steps called steps.js

You can read about all the different configuration properties for a step here



When the steps has been created, we import the steps and add it to the Joyride component in our app





And that is it! 

Here is a working example in Codesandbox





Storing when a user has seen the tour

Having a guided tour is nice, but seeing the same tour every time we load a page will annoy your users. As a bonus I will show you how you can use local storage to keep track of which steps your users has seen in your application.



First we will create a function to read from local storage



This function will let us fetch the item stored under the joyride-guiding key. As I am using Typescript, I tell the code that when I return JSON.parse, the type returned will be of type JoyrideTours.

We will also need a function to store some state in local storage



Here I just stringify the object tours and save them to the key JOYRIDE_LOCALSTORAGE_KEY in local storage.

Finally, we need to be able to listen for the callback event from the tour. We will do that with a new function, connected to the callback-property from the Joyride component

In this last block of code, we define a function handleJoyrideCallback which takes a callback from Joyride, as well as our own defined page variable. We then check wether the status is equal to STATUS.FINISHED or ACTIONS.CLOSE, and if they are, we store in local storage that the user has seen the page we provided. 

The final piece of the puzzle is to not run the tour if the user has already seen it. Otherwise they will get annoyed. To accomplish this, we do as follows

We get the tours from our local storage, and simply check if the page the user is requesting has not been seen. If not we run the joyride tour, otherwise we do not run it. 



And there you have it, a rather simple implementation of how to make guided tours in your application. Quick and easy.





Joyful onboarding with React Joyride

The internal link abstraction with Next.js less than perfect. Let's create a better one!

I love Next.js. It's a great framework for creating fast websites with my favorite technologies in the world. 

I love the way they support APIs. I love how they let me structure things the way I want. But I hate the way their internal linking API works! And you should too.

Luckily, fixing it is pretty simple. In this short article, we're going to build an abstraction on top that makes stuff… just work.

How does it usually work?

Just to recap, this is what you typically have to do in order to link to another site with Next.js. 

Here's a regular link:

This works fine for external links, but how about internal links? That is – link to another page on your site. Well, it looks like this:

If you want to use a custom component as your link component – like from your component library – you had to add the passHref link as well.

Gah…

A better Link

Dealing with all of that code just to add a good ol' link is just too much. Let's create our own component – let's call it TextLink:



This works well for external links – let's add support for internal links as well!



This works fine – let's add our custom text component as well.

Now, we can use our fancy link component wherever we want!

If you want, you can automatically add the rel="noopener noreferrer" prop automatically, as well for external links. And spread all extra props, so it's super flexible:

And that's it!

I hope you copy-paste this component into your app, and get on with your Next.js app :) 

Create a useful link abstraction in Next.js

«Vi må sørge for at folk ikke kan jukse» sa daværende statsminister Erna Solberg før innføringen av digitale koronasertifikater i Norge. Men myndighetenes teknologioptimisme hjalp ikke mot juks, forfalskning og manglende etterlevelse. Når skal vi forstå at teknologi ikke lever isolert fra samfunnet den brukes i?

I april 2021 foreslo foreslo Carmela Troncoso at et papirbasert koronasertifikat kunne være sikkert nok. Hun problematiserte at et digitalt koronasertifikat ville være «secure by design».

Imidlertid hadde myndighetene allerede bestemt seg. De vurderte at forfalskning av eksisterende vaksinedokumentasjon var «svært enkelt å gjennomføre». En signert QR-kode, derimot, var tilsynelatende løsningen for å unngå forfalskning. Det er dessverre på ingen måte riktig.

Det underliggende problemet

Utrulling av digitale sertifikater som skal fungere i hele Europa er en enorm operasjon. Kryptografi-teknologien som benyttes er velkjent og isolert sett sikker nok. Problemet er håndtering av en omfattende sertifikat-infrastruktur på tvers av mange land. Dette involverer et stort antall virksomheter og treffer så godt som alle voksne mennesker i hele Europa, med ulik kultur, kompetanse, språk og intensjoner. Hastverket med beslutningene, utviklingen og utrullingen øker risikoen for feil og mangler.

Juks med tester og vaksinering

Riggene for testing og vaksinering som er bygd opp i europeiske land er imponerende. Hver eneste dag testes millioner av mennesker på utallige test-sentre spredt utover hele kontinentet. Tilsvarende har land vaksinert opp mot 90% av den voksne befolkningen sin. Dette er sannsynligvis den enkleste måten å få grønt koronasertifikat. At det finnes utro tjenere blant alle involverte, er ikke overraskende.

Manglende håndheving

Kontroll av koronasertifikatene utføres av pubansatte, konduktører, vektere, tollere og en lang rekke andre yrkesgrupper som i stor grad består av vanlige folk. Man skal ikke lete lenge før man finner eksempler som dette:

Denne festen er også illustrerende. Deltakerne har sannsynligvis delt på QR-kodene for å komme inn. Resultatet ble 180 smittede:

Forfalskning og svartebørs

Koronasertifikater gir fordeler til innehaverne innenfor reising, trening, tilgang til konserter og restauranter osv. Dette er forretningsmuligheter for kriminelle. Et marked for forfalskning og salg av koronasertifikater har blitt etablert, illustrert av disse sakene:

Lekkasjer på innsiden

Hemmelige nøkler må utstedes, distribueres og tilbakekalles hvis de lekker eller stjeles. Koronasertifikater skal utstedes til millionvis av mennesker, fra en nyetablert digital infrastruktur på tvers av organisasjoner i mange land. Denne infrastrukturen åpner en helt ny angrepsflate.

I slutten av oktober hevdet en anonym bruker på et nettforum at de hadde tilgang på de private nøklene for utstedelse av sertifikater:

Etter hektisk aktivitet, viste det seg at nøklene ikke var kompromittert. Lekkasjen skyldtes uautorisert tilgang til digitale tjenester for utstedelse av koronasertifikater i enkelte land. Dette illustrerer utfordringen med sikkerhet i denne enorme infrastrukturen på tvers av land.

På samme tid demonstrerte Chaos Computer Club en annen sårbarhet i systemet. De opprettet et falskt apotek i Tyskland, og kunne dermed utstede gyldige koronasertifikat via en sentral løsning. Ingen nøkler på avveie, men omfanget er ukjent/ikke offentlig, og krever omstendelig opprydding i etterkant.

Teknologioptimismen gir oss tunnelsyn

Eksemplene ovenfor viser at koronasertifikatene kan forfalskes, jukses med og misbrukes på mange måter. Husk også at dette er hendelser som har blitt oppdaget. Det overveiende sannsynlig at mørketallene er betydelige.

Folk som har jobbet med digital tjenesteutvikling kjenner disse risikoområdene. Selv om signerte QR-koder isolert sett er vanskelig å forfalske, er det utallige muligheter for juks. Om omfanget av juks ville vært større eller mindre med de eksisterende gule vaksinebevisene er umulig å si. Sannsynligvis vil de som ønsker å jukse finne måter uansett, mens de fleste vil holde seg innenfor lovverket.

Politiet synes iallefall at en papirlapp er tilstrekkelig på Oslo Lufthavn 😉

I alle tilfeller er en kostbar og omfattende infrastruktur for innbyggerkontroll rullet ut i hele Europa. Den er det verdt å ha et kritisk blikk på i fortsettelsen.



7-Dec

Today's posts

Typesafe forms in TypeScript

Brannfakkel - Er design nødvendig da? (Del 1 av 6)

Joyful onboarding with React Joyride

Create a useful link abstraction in Next.js

Koronasertifikater - Vi må sørge for at folk ikke kan jukse!