Welcome to the seventh installment of Bekk Christmas

Welcome to our advent calendar. Or Christmas calendar. I never really figured out the politically correct way to phrase it. But it’s here. It’s jolly. And it’s full of original content. While the days become shorter and darker, enlighten yourself with bright ideas, thoughts and learnings.

Bekk has always been incredibly invested in our sharing culture. Our entire organization is rigged towards helping ourselves learning new things, discussing them with colleagues and sharing them with the industry. And bekk.christmas is one of the best ways this manifests itself for the people looking in.

This year, we’re happy to provide you with over 100 original articles, created exclusively for Bekk Christmas. They’re all produced by Bekk engineers, designers, strategists, product owners and team leads, sharing their insights and unique experiences with the rest of you – and reinforcing their learning as they do it.

You’ll find between 3 and 5 articles in both Norwegian and English most days, and we hope you learn something new from them.

If you’re a fan, make sure to share them with your colleagues.

Happy holidays to you all!

Bekk Christmas 7.0

Enten du lager et bibliotek eller lager React-komponenter for din egen del, er det en teknikk du bør kjenne til: polymorfisme. Det er når én ting kan ta flere former, som når en knapp kan opptre som en lenke. Brukt riktig, kan det redde deg fra å vedlikeholde ulike varianter, samtidig som det kan gi brukerne fleksibiliteten de trenger fra komponenten. 

I denne teksten vil jeg vise deg hvordan du kan utnytte 2 av de mest kjente måtene å få til polymorfisme i React: “as”- og “asChild”- mønstrene.

Jeg har lagd en nydelig, juleinspirert knapp. Ta en titt!

Den har en lekker animasjon idet den hviler, og den kommer virkelig til live i det du hovrer den. Implementasjon og bruk ser slik ut:

Som du ser over, så er det kun en knapp akkurat nå, men jeg ønsker å også kunne bruke den som en lenke.

Hvordan får jeg til det?

as-mønsteret

Å skulle rendre en lenke seende ut som en knapp er en vanlig problemstilling. Dette kan løses med as-mønsteret. 

En av måtene å implementere as-mønsteret er å utnytte en helt spesiell egenskap i JSX:

Om et element har stor bokstav, vil React tolke det som en elementtype. Da vil React rendre elementtypen basert på variabelens verdi. 

Her bruker vi dette, ved å ta verdien i as-propen og putter det inn i variabelen Tag:

Så om as har verdien "a", vil elementtypen være en anchor-tag, og ikke en knapp:

Det er forresten ikke noe magisk ved å bruke akkurat “Tag”. Også “Component” er et vanlig navn, men du kan bruke hva enn du vil så lenge variabelen er med stor forbokstav.

Resultat ser slik ut. Legg merke til at oppe i venstre hjørnet i tooltipen vises det at den ene knappen nå er av elementtype <a>:

TypeScript med as-mønsteret

Akkurat nå har vi ingen typesikkerhet, så konsumere av komponenten kan sende inn alt mulig rart, inkludert ikke gyldige elementtyper. 

For å få til riktig typing av as, kan vi type propen til en generisk type T, og la den arve av ElementType. Det betyr at as-propen nå kan være gyldige elementtyper, som <a> eller <button>:

For å få riktig typing av propsene bruker vi ComponentPropsWithoutRef. Vi sender den vår generiske type, så vi får en advarsel om vi prøver å sette ikke-gyldige props for et element, som å sette href ved as="button".

Videre i komponenten, ser implementasjonen slik ut, hvor vi også må si ifra om generisk type til funksjonen:

Vi har nå en knapp implementert med as-mønsteret som tillater gyldige elementtyper, og som vil gi riktig typede props!

Fra as til asChild

as-mønsteret er én måte å få til polymorfisme, hvor du innad i komponenten definerer hvordan andre elementtyper skal håndteres. Et annet polymorfistisk mønster er å bruke asChild, som lar barnet bestemme forelderens elementtype.

Her er LinkButton implementert med hver av mønstrene:

Slik asChild fungerer, er å sende props fra forelderkomponenten til barnekomponenten. I dette tilfellet er første barn til knappen en lenke, så det rendres som en lenke.

Etter å ha sett asChild i flere biblioteker, ble jeg overrasket over at dette faktisk ikke er en innebygd React-prop, men noe som må implementeres — i likhet med as-propen.

Implementere asChild

Med asChild-mønsteret ønsker vi å rendre en forelder som barne-elementets elementtype, men samtidig også beholde forelderens props. En enkel implementasjon av asChild kan se slik ut:

Hvis asChild ikke er valgt, rendrer vi den vanlige knappen.

Men når asChild er valgt, benytter vi en funksjon du kanskje ikke bruker hver dag: kloning. Med React.cloneElement kloner vi barne-elementet, med dens elementtype og alle dens verdier. Andre-argumentet er mulige andre egenskaper det klonede elementet har, og her putter vi forelderens props. På denne måten arver <a>-tagen Button sin stil og oppførsel, men bevarer barnet sin elementtype.

Denne enkle implementasjonen får frem poenget, men den håndterer ikke situasjoner som stil- og prop-kræsj. Biblioteket Radix har ekstrahert ut denne logikken i en komponent de kaller Slot.

Det er altså denne implementasjonen jeg vil anbefale om du skal støtte asChild:

Når skal jeg bruke as og når skal jeg bruke asChild?

Når det kommer til å velge mellom as og asChild, kan det være uklart hvilken du bør gå for, siden begge tilnærmingene kan oppnå lignende resultater.

Når det konkret kommer til LinkButton, har jeg en preferanse:

Tydelig Rollefordeling: Med asChild blir skillet mellom hvilket element som håndterer styling og funksjonalitet tydeligere. Button styrer stilen, mens <a>-tagen tar seg av navigasjonsaspektet.

Fleksibilitet: asChild gir fleksibilitet til å endre barneelementet, som å bytte fra en <a>-tag til en <span>, uten å miste stylingen som Button tilbyr.

Unngå Kompleksitet: Denne tilnærmingen unngår kompleksiteten som kan oppstå ved å måtte støtte flere elementtyper direkte i Button. Med as-tilnærmingen er det fort gjort å skulle støtte for mange utgaver, som gjør koden uleselig.

Det er imidlertid situasjoner hvor asChild ikke er mulig, som med en Heading-komponent som skal støtte flere overskriftsnivåer (h1, h2, h3, osv.). Her gir det mening å endre elementtypen direkte med as-propen.

Det er også et spørsmål om du i det hele tatt skal bruke polymorfisme. Når du ser at ting ligner på hverandre, kan det gi mening å kombinere dem med polymorfisme. Men om du har mange særtilfeller avhengig av elementtype, er det enklere å holde dem separate.

Avsluttende ord

Det finnes mange måter å lage en LinkButton på, og to av dem er med as-prop eller asChild. Det er et tveegget sverd, siden polymorfisme kan også gjøre koden mer komplisert. Men brukt riktig, er det verktøy som kan gjøre koden din mer leselig og vedlikeholdbar.

Om du er nysgjerrig på hva som ligger bak Slot-implementasjonen, har Jacob Paris en mer detaljrik forklaring her: https://www.jacobparis.com/content/react-as-child

Om du vil enda mer i dybden av polymorfisme og generics i TypeScript, ta en titt på Emmanuel Ohans guide her: https://www.freecodecamp.org/news/build-strongly-typed-polymorphic-components-with-react-and-typescript/

Polymorfisme i React: 2 mønstre du må kjenne til

“Nå har vi vaska kode, og vi har slettet alt. Og vi har krasja appen, og databasen falt."

Dette var nesten min julelåt da jeg skulle slette litt kode sist. På 5 minutter kan du lære hvordan gjøre det samme OG hvordan du kan unngå å gjøre nøyaktig som meg, men bedre.

Mange har blitt sitert på ulike varianter av “den eneste feilfrie koden er den som aldri er skrevet”. Jeg mener at alt håp allikevel ikke er ute (beklager, Turistforeningen) selv om koden er skrevet. Spesielt om den ikke lenger er i bruk. Og så er ikke det alltid like lett i alle kodespråk å si om koden faktisk er i bruk. Heldigvis er Kotlin ganske god på dette, siden vi ikke har så mye globale greier (Ja, jeg ser på deg, JavaScript).

Om du allikevel ikke er overbevist om at å slette ubrukt kode er en lur ting, så tenk tilbake. Tilbake til forrige gang du måtte sette deg inn i en ny kodebase. Det er nok av ting å lære seg, om du ikke må lære deg masse kode som ikke gjør noen ting også.

“Ja, men tenk så praktisk denne kodesnutten kan være i fremtiden om noen andre skal løse et lignende problem”. Joda. Men tenk så upraktisk det kan være å finne en kodesnutt med bug i, og det er 20 ulike “paymentHelperFunction()” som i koden din, og 13.5 av de er rene villspor. Så la oss slette litt ubrukt kode. Git husker den uansett.

TL:DR;

“Analyze | Run inspection by name “ og skriv “unused symbol”. Ikke slett enum-verdier eller default-verdier på ting som kommuniserer ut


Hvordan finne død kode?

Det er lekende lett å finne kode som ikke er i bruk med …drømroll… Intellij! 🎉

Og det er mange veier til mål. Min favoritt er den visuelle veien. Selv om jeg ellers foretrekker terminaler og snarveier. Intellij har mange knapper og fancy funksjonalitet, og det er litt cockpit-stemning for min del. Så om det er visuelt tydelig at jeg ikke gjør noe dumt nå, da blir jeg generelt glad.

Vi starter i filutforskeren, standard funnet til venstre i Intellij-en din. Høyreklikk på mappen som inneholder alle filene du vil skanne gjennom. F.eks. `src`. Velg `Analyze` fra menyen og det litt obskure navnet “Run inspection by name”. Her får du et magisk felt du kan skrive regelnavn fra hvilket som helst kodespråk. Veldig brukervennlig med andre ord.

Kodeordet vårt er ikke “simsalabim”, men “unused symbol”. Dette er Kotlins “du-bruker-ikke-denne-greia”-regel. Trykk enter og "OK", og Intellij er i gang. Ubrukt kode vil bli ramset opp i fleng av Intellij, og du kan slette i vei.



Simsalabim!



Jeg lovte også at du skulle kunne unngå å brenne ned prodtreet på julaften med slettingen din. Om du er interessert i å unngå det, så les videre!


Hvordan ikke ta ned prod*

*jeg garanterer ingenting. 

Fellesnevneren for fallgruvene jeg har gått i personlig er at de har med ting utenfor min egen kodebase å gjøre. Vi snakker altså gjerne HTTP eller andre alternativer. Heldigvis finnes det ulike måter å håndtere disse på, som du kan lære av meg istedenfor å tråkke i sildesalaten.

Fellesløsningen som du kan bruke uansett hva Kotlin mener er å si “Jeg vet best, hold kjeft.”. Eller @Suppress(“unused symbol”) som det heter på kotlinsk. Er du litt hyggelig med nestemann så legger du også inn en forklaring, eller kanskje til og med en lenke hit? 🤓


Jackson krever at enum-verdier finnes.

Enum-verdier som ikke har noen verdi for din kodebase (🥁) er Kotlin overbevist om at helt trygt å fjerne. Tenker du som meg at Kotlin vet nok best, så venter det en del knall og fall på deg også. Det har seg nemlig slik at Kotlin ikke helt klarer å se at Jackson kanskje kommer til å krasje på manglende enum-verdier. For det er det som er standardoppsettet. Om du absolutt ikke ønsker å ha disse enum-verdiene i koden din har vi heldigvis valgalternativer.

Be de settes til null. Du vil så klart da begynne å måtte håndtere null-verdier i koden og typene dine. Reglen setter du på objectMapperen din (DeserializationFeature.READ_UNKNOWN_ENUM_VALUES_AS_NULL)

Be de settes til en default-verdi. Det er kanskje en business-case som forklarer hvorfor det finnes masse enum-verdier du gir blanke f* i. Da gir det gjerne mening å gi dette et navn og en egen enum-verdi som sier hvordan det caset skal håndteres. Samme som over så settes dette i objectMapperen. (DeserializationFeature READ_UNKNOWN_ENUM_VALUES_USING_DEFAULT_VALUE)

Generer API-klienten din automagisk (f.eks. med en OpenAPI-kodegenerator) og hold den genererte koden utenfor mappen du ber Intellij lete gjennom.



Default-verdier som aldri blir satt til noe annet

Ubrukt sier Kotlin, ubrukt sier du, 400 Bad request sier mottakeren av API-requestet ditt. Om API-et du skal snakke med krever at et felt blir satt av deg, og ikke at de har satt en standardverdi på sin side, så kan du igjen gå i baret. Igjen kan du reddes av genererte API-klienter. Ellers er suppress igjen din venn.

Julerengjøring i Kotlin på 5 minutter

Whether you're making a library or making React components for your own sake, there's one technique you must know: polymorphism. It's when one thing can be multiple shapes, as when a button can act as a link. Used correct, it can save you from maintaining many variants, and at the same time give your users the flexibility they need. 

In this text I will show you how to utilize two of the most known ways of implementing polymorphism in React: the "as"- and "asChild"-patterns. 

I have made a lovely, Christmas-inspired button. Take a look!

It has a nice animation as it rests, and it really comes to life when you poke it. Implementation and use looks like this:

As you can see above, it's just a button right now, but I want to be able to use it as a link as well. 

How do I achieve that?

as pattern

Making a link look like a button is a common problem. This can be solved with the as pattern. 

One of the ways to implement the as pattern is to exploit a very special property in JSX: If an element has an uppercase letter, React will interpret it as an element type. Then React will render the element type based on the variable's value. 

Here we exploit this, by moving the value from the as prop into the variable Tag:

So if as has the value "a", the element type will be an anchor tag, and not a button:

By the way, there is nothing magical about using exactly "Tag". Another common name is “Component”, but you can use whatever you want as long as the variable is capitalized.

The result looks like this. Notice that in the top left corner of the tooltip it appears that one button is now of element type <a>:

TypeScript with the as pattern

Right now we have no type safety, so consumers of the component can pass in all sorts of weird stuff, including invalid element types.

To achieve the correct typing of as, we can type the props to a generic type T, and let it inherit from ElementType. This means that the as props can now be valid element types, such as <a> or <button>:

To get the proper typing of the props, we use ComponentPropsWithoutRef. We pass it our generic type, so if send invalid props, such as trying to set href for as="button", we will get a warning.

Further in the component, the implementation looks like this, where we also have to declare the generic type for the function:

We now have a button implemented with the as pattern that allows valid element types, and will provide properly typed props!

From as to asChild

The as pattern enables polymorphism by allowing components to define handling of different element types internally. In contrast, the 'asChild' pattern offers an alternative approach to polymorphism, using the child element to define the parent's element type.

Here is the LinkButton implemented with each of the patterns:

The way asChild works is to send props from the parent component to the child component. In this case, the first child of the button is a link, so it is rendered as a link.

After seeing asChild in several libraries, I was surprised that this is actually not a built-in React prop. But, similar to the as prop, it has to be implemented.

Implementing asChild

With the asChild pattern, we want to render a parent as the child element's element type, but at the same time also keep the parent's props. A simple implementation of asChild might look like this:

If asChild is false, we render the button as is.

But when asChild is true, we use a feature you might not use every day: cloning. With React.cloneElement we clone the child element, with its element type and all its values. The other argument is possible other properties the cloned element has, and this is the place we put the parent's props. This way, the <a> tag inherits Button's style and behavior, but preserves its child element type.

This simple implementation gets the point across, but it doesn't handle situations such as style and prop crashes. The library Radix has extracted this logic in a component they call Slot.

It is therefore this implementation that I would recommend if you are going to support asChild:

When should I use as and when should I use asChild?

When it comes to choosing between as and asChild, it can be unclear which one you should go for, since both approaches can achieve similar results. 

When it comes specifically to the LinkButton, I have a preference:

Clear distribution of roles: With asChild, the distinction between which element handles styling and functionality becomes clearer. Button controls the style, while the <a> tag takes care of the navigation aspect.

Flexibility: asChild provides flexibility to change the child element, such as switching from an <a> tag to a <span>, without losing the styling that Button provides.

Avoid Complexity: This approach avoids the complexity that can arise from having to support multiple element types directly in Button. With the as approach, it is easy to have to support too many editions, which makes the code unreadable.

However, there are situations where asChild is not possible, such as with a Heading component that needs to support multiple heading levels (h1, h2, h3, etc.). Here it makes sense to change the element type directly with the as-props.

There's also a question of whether you should use polymorphism at all. When you see that things are similar, it can make sense to combine them with polymorphism. But if you have many special cases depending on the element type, it is easier to keep them separate.

Final words

There are many ways to create a LinkButton, and two of them are with as- or asChild-prop. It's a double-edged sword, since polymorphism can also make the code more complicated. But used correctly, there are tools that can make your code more readable and maintainable.

If you are curious about what lies behind the Slot implementation, Jacob Paris has a more detailed explanation here: https://www.jacobparis.com/content/react-as-child

If you want to dive even more into polymorphism and generics in TypeScript, take a look at Emmanuel Ohan's guide here: https://www.freecodecamp.org/news/build-strongly-typed-polymorphic-components-with-react-and-typescript/

1-Dec

Today's posts

Bekk Christmas 7.0

Polymorfisme i React: 2 mønstre du må kjenne til

Julerengjøring i Kotlin på 5 minutter

Polymorphism in React: 2 patterns you must know