Har du kjent på utfordringer med å ta i bruk OKR for et utviklingsteam? Er produktstrategien din for svevende? Er du lei av å høre at vi skal jobbe "tight-loose-tight", når ingen klarer å forklare hva dette egentlig innebærer? Modningsreisen mot målstyrte team er krevende, og den setter betydelige krav til innsatsen man må legge inn for å komme i mål. 

Vi befinner oss i et paradigmeskifte: Vi lager digitale produkter etter en metodikk som er radikalt annerledes enn hvordan vi gjorde det tidligere. Tidligere var det klassiske prosjekter som var standarden. Nå er det autonomi, målstyring og kontinuerlig leveranse som står i fokus. Omstillingen er mer omfattende enn mange innser når man starter. I denne artikkelen skal jeg ta for meg hvorfor dette er en totalolmveltning, hvilken kompetanse man trenger for å lykkes med det, samt hvordan modningsreisen typisk ser ut.

Hvorfor er omstillingen en totalomveltning?

Omstillingen er så omfattende fordi vi snur om på veldig mye, både i og rundt utviklingsteam. La oss starte med målbildet vårt, som ofte beskrives som «tight-loose-tight»: Vi ønsker at teamet har en tydelig definert retning og eierskap til det overordnede målbildet (den første tighten). Deretter skal teamet jobbe autonomt med å dekomponere dette målbildet til tiltak som vil bringe oss nærmere (loose, det er ikke detaljstyrt hva teamet jobber med). Avslutningsvis skal effektene (merk, ikke leveransene) som teamet leverer måles og følges opp (den siste tighten). Dette kan visualiseres som følger:

La oss hoppe noen år tilbake. Gigantprosjekter var standarden innenfor IT, hvor kravspesifiseringen om nøyaktig hva som skulle lages var jobbet med i årevis før en eneste kodelinje ble skrevet. Det var ikke uvanlig at leverandører skrev hundrevis av sider i en tilbudsprosess, og det kontraktuelle grunnlaget bestemte hva som skulle lages. Dersom prosjektet gikk skikkelig dårlig kunne man i verste fall havne i retten, hvor det ble diskutert hva man hadde laget sammenlignet med hva man hadde blitt enige om at skulle bli laget.

Fra perspektivet til et utviklingsteam hadde man tilnærmet ingen innflytelse på hva man skulle gjøre. Teamets ansvar var å implementere det som hadde blitt bestemt. Det var følgelig også streng kontroll på leveransene til teamet, for å sikre at disse var i tråd med det man hadde blitt enig om på forhånd. Når implementasjonsjobben var ferdig, gikk teamet videre til andre oppgaver. Det var ikke aktuelt at de skulle jobbe med gevinstrealisering eller måloppfølging. Ansvaret for det lå på utsiden av teamet, gjerne hos leder- eller strategifunksjoner høyere opp i virksomheten. Med andre ord hadde ikke teamet noe forhold til sine effekter. Vi kan beskrive dette som "loose-tight-loose" og visualisere det som følger:

Når vi ser dette historiske perspektivet opp mot målbildet ser vi at transformasjonen krever en totalomveltning av hvordan vi jobber. Dette krever ny kompetanse og kunnskap i teamene, samt i resten av virksomheten som er involvert i digital produktutvikling. 

Hvilke fagfelt må vi beherske for å forsere dette gapet?

Vi må ha inngående kompetanse på fagfeltene som lar oss jobbe målstyrt og effektdrevet. I korte trekk er det tre fagfelt som utmerker seg som sentrale, som vi vil se nærmere på: Målstyring, hvordan jobbe med hypoteser, og hvordan være datadrevet.



1. OKR

Litt forenklet kan man si at målstyring handler om å styre etter mål, heller enn å styre etter leveranser. Objectives and Key Results (OKR) er rammeverket alle har hørt om, og som typisk brukes for å operasjonalisere målstyring for utviklingsteam. Det er skrevet mye bra om hva som utgjør gode ambisjoner og gode nøkkelresultater, og vi går derfor ikke videre inn på det her. 

Et moment jeg opplever at er underkommunisert, er hvor lang tid det tar fra et team starter med OKR for første gang, til man får en betydelig effekt ut av det. En svært dyktig kollega fortalte meg en gang at dette gjerne ligger på mellom 12 og 24 måneder for et team. Jeg tror det stemmer ganske bra. Ofte er man svært reaktiv i starten, og det beholdes gjerne en predefinert backlog parallelt med OKRene i en lang periode. Gradvis lærer man seg å dekomponere nøkkelresultatene til tiltak. Disse tiltakene erstatter den tradisjonelle backlogen over tid. 

Når samtlige oppgaver er utledet som tiltak fra nøkkelresultater er man i mål. Å komme dit krever kontinuerlig innsats og støtte fra både teamet og aktørene rundt: Det holder ikke å bare vente og tenke at det vil gå seg til over tid. For å lykkes med OKR i praksis må vi tenke på sammenhengene mellom hva vi ønsker (ambisjonene), hvordan vi måler om vi er på rett vei (nøkkelresultatene) og hva vi gjør (tiltak). Et sentralt verktøy som hjelper oss å konkretisere og tydeliggjøre disse sammenhengene er:



2. Hypotesedrevet metodikk

En sentral utfordring for å mestre bruken av OKR er det store gapet mellom et nøkkelresultat og gode tiltak. Et nøkkelresultat kan eksempelvis være å øke kundetilfredshet med en tjeneste, få flere kunder, eller øke bruken av tjenesten. Disse er brede av natur, og det er i teorien en mengde tiltak som vil bidra. Hvordan finner vi da de tiltakene som treffer best? I min erfaring er hypoteser et svært nyttig verktøy for å utlede gode tiltak fra nøkkelresultater. 

Gode hypoteser baserer seg på kvalifiserte gjetninger om hva vi tror om brukerne og kundene. Her er vi også inne på selve kjernen i hvorfor tight-loose-tight er et målbilde: Det er folka i teamet som er best posisjonert for å komme med disse kvalifiserte gjetningene. Over tid vil de bygge opp en forståelse for både domenet, brukerne og kundene. Dette er en betydelig investering, og noe vi bør få verdi for. 

Selve gevinsten i tight-loose-tight er nettopp det å få utnyttet potensialet som ligger i teamet. Grunnlaget for gode hypoteser baserer seg på både kvalitativ og kvantitativ innsikt, som tar oss videre til vårt siste fagfelt:



3. Datadreven 

Du må bli datadreven for å få den kvantitative innsikten som trengs for å finne de beste hypotesene. Videre er det essensielt at vi har kvantitative data for å måle effekten i andre enden. Så langt har fagfeltene fokusert mye på den første tighten og loosen i midten, men den siste tighten er også viktig: Det er her vi følger opp at teamene har levert på det de har forpliktet seg til. Dette lener seg svært tungt på at man er datadrevet. De gode nyhetene er at dette er relativt enkelt å komme i gang med: Det finnes mange gode verktøy for å registrere, visualisere og følge opp data. 

Datadrevenhet har vært i vinden de siste årene, som gjør at kompetansen man trenger er lett tilgjengelig. Merk at selv om det er lett å komme i gang med å jobbe med data, er det ikke lett å bli datadrevet. Det er i seg selv en betydelig modningsreise, og utenfor omfanget til denne artikkelen.



___



Samtlige teammedlemmer bør ha en grunnleggende forståelse for disse tre fagfeltene, og hvordan teamet er ment å jobbe. Lykkes man ikke med det vil det være vanskelig å nå målbildet om å drive tight-loose-light produktutvikling. Som en kollega skrev i en bloggpost allerede i 2013: 

«Jeg vil jobbe med utviklere, ikke programmerere!»

Alle i teamet må bidra med sin kunnskap, og ikke utelukkende være en ekspert på sitt fagfelt. Det holder ikke at en teamleder eller produkteier har god kontroll: Da er vi nesten tilbake til der vi startet med en bestiller! Min hypotese er at dette vil være essensiell basiskompetanse for alle som lager digitale produkter om få år.



Hvordan ser modningsreisen typisk ut?

I modningsreisen mot målbildet om målstyrte team vil et team som regel gå i en del fallgruver. Min erfaring er at man veksler mellom overslag mot for mye autonomi og for mye kontroll. En typisk modningsreise ser ut omtrent som følger:



La oss se nærmere på disse 4 stadiene:



1. LTL (loose-tight-loose)

Beskrivelse: Dette er utgangspunktet vårt. Vi får bestillinger, og teamet har lite forhold til både de overordnede målene og effektene deres produkter har.

Utfordringer: Vi utnytter ikke potensialet i teamets kunnskap om brukerne, kundene og domenet. Vi har ikke fått tydeliggjort retningen for teamet, og teamet har ikke eierskap til sine effekter. 

Hva bør man jobbe med? Overordnede mål må defineres og tydeliggjøres. Teamet må ta del i oppgaveutformingen. Effektene som teamets produkter har må synliggjøres.

2. LLL (loose-loose-loose)

Beskrivelse: Vi skal jobbe med autonome team, og har skjønt at det er viktig å involvere teamet i å definere oppgavene de skal jobbe med. Dessverre er ikke retningen forstått, og vi har ikke fått på plass gode koblinger enda. Teamet har kanskje definert OKRer, men de brukes i liten grad til proaktiv utledning av oppgaver: Det teamet jobber med var bestemt uavhengig av OKRene (og gjerne før de ble satt). Vi har heller ikke fått på plass målinger enda, i alle fall ikke på en måte som gjør at det er disse teamet blir målt på.

Utfordringer: Dette kan beskrives som «hjemme alene-fest», og er et typisk overslag mot autonomi. Autonomi uten retning og ansvarliggjøring er ikke godt nok. Ambisjonen må være myndiggjorte team, ikke full autonomi.

Hva bør man jobbe med? Tydeliggjør de overordnede målene og retningen teamet jobber mot. Invester i forståelsen av hypoteser og jobb mot å bli datadrevet. Husk at kvalitative data, eksempelvis det man får fra klassisk innsiktsarbeid, er vel så verdifullt som kvantitative. Dette kan hjelpe til å tette gapet i en fase hvor teamet jobber med å få til en god rigg for kvantitative data. Ansvarliggjør teamet på å måle og kommunisere sine effekter. 

3. TTL (tight-tight-loose)

Beskrivelse: En svært vanlig motreaksjon på «hjemme alene-festen» er å gå tilbake til overslag mot kontroll. Som regel er man enige om at hovedårsaken til autonomioverslaget var at retningen ikke var godt nok definert. Det jobbes godt med dette, men parallelt vil ledere ofte gå tilbake til bestillinger for å føle at de har kontroll. Typisk har man ikke fått til feedback loopen ordentlig enda, det vil si ansvarliggjøringen av teamets evne til å levere på retningen som er satt. Dette følger naturlig ettersom retningen ikke var godt nok forstått.

Utfordringer: Ettersom teamet jobber etter bestillinger får vi ikke utnyttet deres kunnskap fullt ut. Mangel på gode data rundt effekter, samt kommunikasjon av disse, gjør at det blir vanskelig å måle teamet på dette heller enn utførte leveranser.

Hva bør man jobbe med? Å tydeliggjøre koblingene mellom teamets OKRer og retning ved hjelp av hypoteser vil bidra til at ledere kan slippe kontrollen og likevel føle seg trygge: Teamet har vist en forståelse for hva som skal oppnå, og har en klar tanke om hvordan de skal bidra. Videre må teamet jobbe med å bli datadrevne: Både for å understøtte hypotesene, samt kommunisere effektene de oppnår. Sistnevnte vil være viktig for at ledere skal føle at de ikke trenger å bestille leveranser.

4. TLT (tight-loose-tight) 

Beskrivelse: Vi har fått på plass gode målinger og kommunikasjon rundt effekter. Retningen er godt forstått og ligger til grunn for teamets OKRer, som brytes ned løpende og proaktivt i tiltak av teamet selv. Gradvis forsvinner behovet for bestillinger, da teamet finner ut av hva som er de rette oppgavene å jobbe med på bakgrunn av hypoteser. Vi har gode metrikker og god kommunikasjon rundt teamets effekter som følge av at vi er datadrevet. Ledelsen måler teamet på deres effekter, heller enn leveranser.



___



Ikke alle modningsreiser er like, og fallgruvene skissert over er ikke de eneste man kan havne i. Jeg har valgt å trekke frem de jeg har observert flest av, og konkretisert disse så godt det lar seg gjøre. Som nevnt innledningsvis er min opplevelse at omfanget og varigheten på en slik modningsreise undervurderes. Derfor er vi tjent med å begynne å sette ord på dette og diskutere. Helst så tydelig som mulig med faktiske eksempler, heller enn overordnede buzzwords: Eksempelvis er det noe helt annet å lese om OKR-rammeverket og å operasjonalisere det i praksis for et utviklingsteam. 

For de som befinner seg i starten av modningsreisen mot målstyrte team, og de som akkurat har begynt: Vær tålmodig! Dette er en krevende transformasjon, og det vil ta tid. Underveis vil teamene og andre interessenter ha overslag i flere retninger. Dette er en naturlig del av læringsprosessen, og noe man må gjennom for å komme i mål. 

Det grunnleggende premisset for målbildet er som nevnt verdien som ligger i kunnskapen til teammedlemmene. Vi ønsker å få utnyttet dette til det fulle, og stoler på at de kjenner mulighetene bedre enn noen andre. I tillegg vil denne måten å jobbe på være mer motiverende: Teammedlemmene får større eierskap til det de jobber med i kraft av at de blir ansvarliggjort, og ved at de får innsikt i formålet til teamet. Dette gir mer produktive og effektive team, noe Google fant i Project Aristotle og som Dan Pink skriver om i Drive (se Drive oppsummert på YouTube). 

Digitalisering har et mye større potensiale enn å "sette strøm på papiret": Vi kan revolusjonere måten tjenestene våre fungerer på. En viktig forutsetning for å utnytte dette potensialet er målstyrte og myndiggjorte team. Vi må slutte å tenke at X timer fra en utvikler skal gi Y kodelinjer. Kodelinjer gir ikke verdi i seg selv, og derfor er det heller ikke dette teamene bør styres ut fra. Noen ganger er det beste en utvikler kan gjøre å ta på seg en refleksvest, gå ut og møte kundene. Det blir ikke mange kodelinjer av det, men det er likevel svært verdifullt! 

De som sitter tettest på, er de som får den største ekspertisen. Vår jobb er å tilrettelegge for dem. Det gjør vi ved å ha målstyrte team. 



Modningsreisen mot målstyrte team

Designdrypp er en artikkelserie hvor forskjellige designere fra Bekk forteller om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips!





Hvem er jeg?

Navn: Lukas Aasbø

Alder: 28

Fra: Bærum

Studerte: Grafisk Design ved Westerdals Oslo ACT

Jobbet som designer i 6 år

Si litt om: hvorfor ble du designer?
Så lenge jeg kan huske har jeg vært glad i tegning, formgivning og det kreative - enten det er grafikk, ord eller musikk. Jeg lærte allerede i barnehagen å tegne en 3D-kube (selvskryt), og mamma var sikker på at hun hadde født neste Leonardo Da Vinci - og at hun skulle slippe å jobbe osv. når nådde mitt fulle potensiale. Mamma, beklager. 😢👵🏼

Jeg var i min ungdomsstid usikker på hvordan mine kreative evner skulle forme min fremtid, men den usikkerheten ble visket vekk når russebussen min trengte logo 👶🏼

Jeg lastet ned Photoshop og brukte urovekkende lang tid på å mestre det - bare for å finne ut av jeg måtte bruke Illustrator... Her startet min karriere som grafisk designer, og utviklet seg til en større interesse for grafisk design og kommunikasjon generelt. 🔥

Etter at jeg skjønte det kanskje ikke er så kult å jobbe i Russeservice etter fylte 20, så sluttet jeg der og startet i et reklamebyrå. Etter noen år der jobbet jeg i et designbyrå før jeg startet her i Bekk 🥳

Så jeg ble designer for det har jeg alltid vært. 💥


Hva gjør jeg?
Jeg jobber med å redesigne Coop sin medlems app. Den skal fylles med masse nytt innhold og nye funksjoner, samt få en stor oppussing på det visuelle. På dette oppdraget sitter jeg heldigvis sammen med Robert og Linn fra Bekk, og mange andre flinke som jobber i Coop. 👨‍👩‍👦

Dette er et utrolig morsomt og lærerikt oppdrag. Vi har fått være med fra starten av prosjektet, og fått være med å forme både appen og hvordan vi jobber som et team. Pluss det er en iskremboks fylt av Royal Trippel rett ved arbeidssonen vår 🍦🤤



Hvilket tips ville jeg gitt meg selv i starten av oppdraget/karrieren?

Bruk mer tid på å lære deg å argumentere godt for valgene dine. Gjør klar noen stikkord på hvorfor vi burde følge løsningen min, istedet for å alltid ta alt på sparket. Gamle tanker forsvinner fort i diskusjoner og da er det lurte å ha noe konkret du vet du vil si i forkant. 🗣️

Spør flere folk om mer ting ang. det du lager. Som tidligere designer i reklame- og designbransjen er man vant å sitte litt mer alene, men både på Skuret og Coop sine kontorer sitter det mange flinke folk man kan sparre med ⚔️

Hva eller hvem inspirerer deg?

Hver dag har jeg et sted å dra hvor jeg lærer utrolig mye, utvikler meg som designer og person, har det morsomt og ler. Det er det som inspirerer meg mer enn noe annet. Det er så deilig å jobbe et sted hvor det skjer så mye, og det er så mange ulike folk - alt fra fagkvelder til elektrofester. Noe som fører meg til neste inspirasjonskilde.

Musikk. Det må jeg ha. Hadde du bedt meg velge mellom å være blind eller døv (og jeg er designer), så hadde jeg valgt blind. Sorry ass!

Tilslutt, meg selv. Hvis det er lov å skrive?

Designdrypp med: Lukas Aasbø

I started my career as a developer in 2011. Soon I came upon the problem of a user proving who they are, and what they’re allowed to do. Seemed hard, but I reasoned I would get the hang of it quickly.

That didn’t really happen. Authentication is hard. Authorization is harder.

But. New tools and services make things easier. And today I will share a tiny crazy Kotlin tidbit that made my day a bit easier.

Spring Security, Kotlin and DSLs

Spring is the most popular web framework in the JVM sphere, and of course it comes with its own security suite. Now, being a Java framework, it uses builders for configuration, which looks something like this:

Not that horrible, really. But we can do better. We are writing in Kotlin, after all.

Tiny bit cleaner, right? But what is actually going on here? Did someone re-write the entire Spring Security Stack to work in a Kotlin-idiomatic way? Looking at the imports, it really doesn’t seem like it. No, the genius culprit is this little line here:

Digging into the definition leads us here:

For those unfamiliar with Kotlin (and indeed many Kotlin users) this might seem daunting. However, this is an idiomatic way to create a Domain Specific Language (DSL) in Kotlin. Let’s unpack it:

operator fun: This means we are overloading an operator, i.e. a built-in part of the language.

HttpSecurity.invoke: This means we are overloading the built-in invoke function, but prefixed with HttpSecurity as its receiver, creating a function that can be called as if it existed as a member function of HttpSecurity. 

The invoke function is the same as calling a function with parentheses. 

When the only parameter of a function is another function, we don’t need the parentheses at all, and can use only curly braces. This is known as a trailing lambda.

httpConfiguration: HttpSecurityDsl.() -> Unit: The invoke function takes in a function with a receiver of type HttpSecurityDsl . Meaning for whatever function we pass in, this will be of the type HttpSecurityDsl.

HttpSecurityDsl(this, httpConfiguration).build(): The invoke function returns an instance of HttpSecurityDsl, passing in the HttpSecurity object and the httpConfiguration function.

We'll look at the HttpSecurityDsl in a bit, but first I want to focus on exactly what it means that we can overload the invoke() function:

Any instance of the type is turned into a callable function!

Think of how in English, everything can be verbed: To cat around; I goblined at home this weekend; did you bus, bike, rollerblade or foot it here?

Well, overloading invoke() is kind of like that. Here is an example:

We can invoke the animals as if they were functions, either by calling .invoke() or by just adding some parentheses. Pretty cool and/or crazy, right?

DSL builders

So what is this mystical HttpSecurityDsl type? If we examine it closer, we find dozens of methods that match closely to the builder methods of the original HttpSecurity. Here is an example:

So here another DSL is started, for specifically configuring HTTP Requests. And this is the basic pattern for nesting configurations, as we did in the securityFilterChain function above.

Creating nested DSLs in this way might seem complicated, but the end result is an extremely clean and readable syntax for building anything from security configurations to type-safe HTML.

Conclusion

So, with the tools of operator overloading, function types with receivers, trailing lambdas and DSL classes, we have extended a regular Java object http of the class HttpSecurity into the starting point of a Kotlin-idiomatic domain specific language for configuring our authentication and authorization. I think that’s pretty crazy.

Start writing your own DSL today, or take a look at Type-safe builders if you want more examples. Start verbing today!

Auth is hard and Kotlin is crazy!

Har du sett React sin Suspense funksjonalitet og tenkt at det kunne vært noe for applikasjonen din? Bare for å få drømmene lettere lagt i grus når du etter nærmere studier ser at Suspense støttes i hovedsak av meta rammeverk som Next.js og Remix? I dagens juleluke ser vi på ulike måter å håndtere datalasting på, og hvordan vi kan forbedre både ytelse og kodekvalitet ved å ta i bruk TanStack Query og Suspense. Vi omgår metarammeverk begrensningen og ser på hvordan vi kan bruke Suspense i en tradisjonell klientside React applikasjon. Dette gjør vi ved å bruke JS biblioteket TanStack Query.

God gammeldags datainnhenting

Før vi dykker ned i TanStack Query og Suspense, la oss raskt se på hvordan man tradisjonelt henter data i en React applikasjon. Uten en eneste avhengighet bruker vi gjerne en useEffect siden man i React ikke kan gjøre asynkrone operasjoner på toppnivå i en komponent. 

Skal man i tillegg ta høyde for at internettlinja mellom nissens kontor på Nordpolen og datasentrene sørafjells er ustabil, bør man også håndtere eventuelle feil.



Denne måten å hente data på er streit nok. Men dette mønstret har noen utfordringer som det kan være verdt å merke seg ⚠️ Dan Abrahamov, en aktiv kontributør til React, har blant annet i denne posten oppsummert noen hovedproblemer:

 Ingen caching. Hvis en bruker navigerer fram og tilbake mellom en komponent, må hen laste data ved hver eneste render.

Race Conditions. Hvis en komponent henter data f.eks basert på en query, er det fort gjort å få bugs med Race Conditions (resultatet avhenger av i hvilken av parallele requests som fullfører sist). 

Må rendre før man kan begynne å laste. Når en datainnlasting skjer i en useEffect starter ikke datainnlastingen før komponenten rendres (og alle parents er rendret). Dette gjør at det tar unødvendig lang tid, og man får gjerne sekvensiell fossfallslasting av data.

I tillegg blir det en del boilerplatekode av denne måten å fetche data på.  



10 år etter React ble lansert, er tendensen at flere og flere frontendapplikasjoner tar i bruk metarammeverk, som Next.js og Remix, som løser mange av de overnevnte problemene for oss. Sitter du imidlertid på en eksisterende "Old School" React app finnes det heldigvis verktøy i kassa for disse også 🙏 La oss ta en titt på ett av de.

TanStack Query - Ett farvell til useEffect

Et eksempel på et bibliotek som håndterer datalasting og tilstand er TanStack Query. Vi har brukt det med hell på prosjekt og det har et rikt og godt API som gjør hverdagen litt smoothere. Samme datalasting som i tidligere eksempler kan nå gjøres ved å kalle på useQuery-hooken:

Ingen useEffect og vi får caching med på kjøpet der altså. useQuery er selve bærebjelken i TanStack Query, i tillegg finnes det også mye annen funksjonalitet for mutations, invalidere cache osv. Men i eksemplet vårt må komponenten fremdeles sjekke hvordan datalastingen gikk og håndtere innlasting og feilsituasjoner. Hva om man bare kunne kastet disse tilstandene oppover i hierarkiet..? Vel, møt React Suspense. I neste seksjon ser vi på hva det er for noe, før vi avslutter med å se på hvordan vi kan ta det i bruk med TanStack Query.

Vi tar en pause med Suspense 

Suspense, lansert i React 16.6, er en innebygd funksjon for å håndtere asynkrone operasjoner, som for eksempel datainnlasting eller fillasting. Intensjonen bak er å gjøre det enklere å lage gode bruker opplevelser i applikasjoner som laster asynkrone data. Essensen i Suspense lar deler av applikasjonen din ta seg en god gammeldags pause mens en eller flere dataoperasjoner skjer lengre ned i komponenthirarkiet. Mens deler av applikasjonen tar en pause vises en fallback komponent som utvikleren selv har definert. Suspense brukes også gjerne sammen med en ErrorBoundary som fanger feil. 

I Gaveønsker komponenten kan vi nå bruke dataen uten å måtte ta masse forbehold:





Dette flytter ansvaret for å håndtere datainnlasting fra selve visningskomponenten som bruker dataen til en komponent lengre oppe i treet, for eksempel en page container. Dette separerer og tydeligjør ansvaret: visningskomponenten kan gjøre det den kan best, vise innhold uten å måtte forholde seg til hvordan det har blitt lastet.  Hvis man laster data fra flere kilder i flere underkomponenter, kan de bruke en felles Suspense og ErrorBoundary slik at alle underkomponenter slipper å håndtere dette selv.



Det er bare et problem med denne koden. Det vil ikke fungere i en vanlig klientside React applikasjon på grunn av tekniske begrensinger i Suspense 😰



⚠️ Tekniske begrensinger ved Suspense

Leser vi dokumentasjonen til Suspense litt nøyere ser vi at Suspense foreløpig har noen viktige begrensinger:

Only Suspense-enabled data sources will activate the Suspense component. They include: Data fetching with Suspense-enabled frameworks like Relay and Next.js.



Suspense-enabled data fetching without the use of an opinionated framework is not yet supported. The requirements for implementing a Suspense-enabled data source are unstable and undocumented.

For vår del betyr dette at Suspense ikke vil fungere, hverken for datalasting med useEffect og med TanStack Query sin useQuery. Suspense vil rett og slett aldri oppdage at det er noe data som lastes. Heldigivis så har nylig TanStack Query lansert fullverdig støtte for Suspense som lar oss gjøre nettopp dette 🙌



💕 Suspense + TanStack Query

Siste versjon av TanStack Query kommer med fullverdig støtte for Suspense og eksponerer tre dedikerte hooks: useSuspenseQuery, useSuspenseInfiniteQuery og useSuspenseQueries. For å bruke Suspense kan vi bare bytte ut kallet vårt til useQuery med useSuspenseQuery.

I denne konteksten er data garantert til å være definert. useSuspenseQuery returnerer ikke loading eller isError flagg, men "kaster" feilen så dette blir håndtert av en ErrorBoundary eller en Suspense definert høyere opp i komponenthirarkiet. Dette gjøres på samme måte som vi så på i et tidligere eksempel:






Til slutt

Vi har i dagens luke dukket nærmere inn på datalastning i React. Vi har sett på problemene med å hente data med useEffect, vi har istedenfor sett på TanStack Query som tar seg av mye av den harde jobben. Videre har vi sett på hvordan vi kan bruke Suspense og ErrorBoundaries for å slippe å håndtere datainnlasting med all kompleksitet i visningskompontene. 



 God koding!



15-Dec

Today's posts

Modningsreisen mot målstyrte team

Designdrypp med: Lukas Aasbø

Auth is hard and Kotlin is crazy!

Slik gjør du datalasting til en glede med React Suspense og TanStack Query