Updating view logic based on some state or props is a common thing to do in a React application, and the go-to method is typically by putting every state update in one or more useEffects. However, this will lead to unnecessary updates and unmaintainable code. Let's take a look at how updating view logic is better by doing it during render rather than useEffects. 

The content of this article is heavily inspired by the new React docs (which is in beta).

Updating view logic in useEffects

Let's say you have a welcoming message you want to show the user, but you want to have different logic whether the user is logged in or not. The first instinct may be to use useEffects to compute the new data. Let's take a look at the example below:

Above you have local state keeping track of whether you are logged in or not and state with a greeting you want to show to the user. In addition, you have a useEffect listening on the isLoggedIn state which triggers whenever this value changes, and it will then update the greeting message. This will lead to unnecessary renders because the useEffect depends on other state variables which first will update, then trigger a re-render, then the useEffect will detect the new values in the dependency array and then perform another update. 

Updating state variables used for view logic in this way is confusing and hard to read. Using useEffect to update view logic in a component will be slow and trigger unnecessary updates down the tree of components as well. And let's not speak of all the potential bugs that may occur if the state variables get out of sync. Remember that useEffects are for side effects, not maintaining your local state or props.

Updating view logic during render

A surprising solution for this issue is to just drop the effect, and rather perform the calculation of the state used for view logic during render. By putting the calculation outside the useEffect the value will be computed at once the value it depends on changes, and it will happen without the re-render as with the useEffect. If we add this solution to the example from above, we get something like this:

This will remove unnecessary re-renders in your component and it will be much easier to read for you and other team members. Less code, less error-prone!

Expensive computations

In some cases, the computation can be very expensive, and you don't want to calculate it on every render if nothing has changed. The solution for caching expensive computations is useMemo. Note that the first render will still be expensive, but it will avoid unnecessary updates if nothing has changed based on what's in the dependency array.

An example with useMemo:

To check whether your calculation is expensive I recommend using a proper debugger (React DevTools) or using timing functions to track how much time the calculation takes. Keep in mind that optimization may also be costly, especially if you do it prematurely. I suggest reading this great article about When to useMemo and useCallback.

TL;DR

Drop the useEffects when updating the state used for view logic based on state or props, just calculate it during render 💥.

Compute view logic during render in React

Do you need help with the Javascript SDK for Application Insights? Look no further! This guide will help you go from zero to hero in no time 📈

Enabling the Javascript SDK for enabling Application Insights in a Next.js application is not as easy as it may sound. This guide will show you how to do it (so that you don’t have to spend as much time as I did on it) ⏳.

Next.js has a problem with not enabling execution of code prior to starting your application (unless you create your own custom server). Hence, there are no obvious files to place the code that is needed to create an Application Insights-instance in you app. 

In this article, a small workaround is presented along with a step-by-step guide on how to enable Application Insights in your Next.js application 🚶.

Step-by-step guide🚶

Install @microsoft/applicationinsights-web using npm or yarn

Create a file where you can initialise and retrieve an appInsights-instance.

Create a component that uses a useEffect to only initialise the appInsights-instance once.

Retrieve the environment variables needed to initialise the appInsights-instance and ensure that the instance is set up the first time a user navigates to any application page.

Track what you want! 🎉



Step 1:

Install @microsoft/applicationinsights-web in node_modules using npm or yarn (I use yarn below) 💻:



Step 2:

Create a file that initialises an appInsights-instance and returns the initialised appInsights-instance when you need it for tracking.

Below is the code that is given to us in the azure documentation 📄

But! Where to place this code? If you place it in _app.js, it will be run every time a file in the pages directory is loaded, moreover, creating new appInsights instances all the time! This is bad. We want it to run only once (because otherwise we would be creating a lot of unnecessary appInsights-instances) 🤔.

Hence, we create this modified version where it is possible to run initAI to initialise the appInsights-instance and get the appInsights-instance by running getAppInsights:



Step 3:

Ensure that we only initialise the appInsights-instance once.

We do this by making use of a useEffect, creating a file with a react component looking something like below.



Step 4:

Retrieving the connectionString from the environment-variables so that the appInsights-instance can be initialised.

As all the code that we have written is client-side, we do not have access to the connectionString (as it is most likely an environment variable). Hence, we need to retrieve it and then drill it down to the component and the functions that we have created — allowing us to initialise the appInsights-instance 🙌.

Below, we use Next.Js’ getInitialProps to retrieve the connectionString-environment-variable (this might change with the introduction of Next.Js 13).



Step 5:

That should be it! You can now track whatever you want.

E.g., tracking a page view 📄 👀



The end

That should be it. And your resulting file structure should look something like this:


Bye 👋

Azure Application Insights using Javascript SDK in Next.js

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

Hvem er jeg?

Jeg er nysgjerrig og drives av å lære, i alt jeg gjør. Jeg har det som plomma i egget når jeg skaper, bygger og noen ganger river ned. Designeryrket passer meg altså utmerket!

Jeg kommer fra det deilige sørlandet, har studert design på Arkitektur- og designhøgskolen i Oslo, sammenliknende politikk på Universitetet i Bergen og har vært i Bekk i fem år. 

Hva gjør jeg?

Nå om dagen jobber jeg med en selvbetjeningsløsning hos Møller Digital. 

Jeg har rollen som UX-designer i et tverrfaglig team, og jobber blant annet med å bruke data som innsikt til å forstå behov og til å forbedre løsningen. Det er både spennende og vanskelig. Data kan være utfordrende å oppdrive og hva som skal måles vanskelig å definere. Men vi prøver. Og når teamet starter et nytt initiativ har vi alltid en hypotese om hvilken effekt det skal ha for sluttbruker og hva vi vil måle for å oppnå denne effekten. 

Det er utrolig kult! 

Jeg opplever at det skjerper fokuset på sluttbruker for hele teamet og de rundt som er involvert. Det bidrar også til at jeg designer enklere og mer tydelige løsninger. Og ikke minst er det veldig motiverende å se hvilken effekt det vi lager har og hvordan det endrer brukeradferd.


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

Ikke bli for potet som prøver å gjøre alt. Jobb tverrfaglig ved å involvere alle de superdyktige folkene som er rundt deg. 

Dagens designtips

I november samlet vi flere av Bekks faggrupper for å snakke om krysningspunktet «Data og brukerinnsikt» – og for en kveld det ble! UX-designere, forretningsrådgivere og utviklere var samlet for å diskutere utfordringer og lære om hverandres perspektiv. 



Hvorfor samlet vi en tverrfaglig gjeng for å snakke om data? Vi ser et stort  forbedringspotensiale i hvordan vi samarbeider rundt datainnhenting og dataanalyse. Konsumenter av data bør vite mer om hvordan data samles, bearbeides og lagres. Datainginører og analytikere bør vite mer om hvordan denne dataen kommer til å bli brukt. Dette må vi som bransje bli flinkere til, slik at vi klarer å ta bedre beslutninger basert på data både i produktteamet og i hele organisasjonen. 

Vi hadde mange gode diskusjoner i løpet av kvelden, og så at hva som ble oppfattet som de viktigste utfordringene rundt temaet varierte avhengig av fagbakgrunn, rolle og erfaring. Diskusjonene gjennom kvelden ble noe todelt:

🚀 Behovet for data i produktteam: Vi som jobber med å kontinuerlig lansere og forbedre funksjonalitet trenger kontinuerlige målinger av produktet vårt for å ta bedre beslutninger. Hvem bruker løsningen? Har vi fått flere til å klikke på denne knappen etter vi endret noe?

🏢  Behovet for data på et strategisk nivå: Vi som setter strategiske prioriteringer trenger data som kan hjelpe oss å forstå prosesser i organisasjonen og sette prioriteringer. Vi trenger ikke like hyppige oppdateringer som et produktteam, men har ofte et større og mer komplekst datasett. Hva slags innsikt kan vi få av den dataen vi har? Hva er den beste måten å skaffe den innsikten?

__________

Fagkvelden ga oss tid til refleksjon rundt temaet og denne artikkelen oppsummerer noe av det vi var innom gjennom kvelden. Under har vi samlet noen inntrykk fra deltakere på fagkvelden:

Samarbeid mellom designer og utvikler for å hente ut innsikt fra data er gull!

Ida – designer i faggruppen Psykologi og adferd

Det var veldig spennende å høre mer om hva utviklere og forretningsutviklere tenker om data og brukerinnsikt. Vi snakket om at det gir stor verdi når utviklere og designere samarbeider om å hente ut innsikt fra dataen ved å diskutere hva tallene representerer fordi man gjerne ser etter litt ulike ting i tallene. Et slikt samarbeid i mitt team har ført til at vi måtte endre tallene vi inkluderte i datagrunnlaget for å få en riktigere representasjon av virkeligheten.

Det kan være overveldende med mye data og det er ikke alltid rett frem hvor man skal starte. Da har det vært godt å alliere meg med noen som kan det tekniske og vet hvordan målingene er satt opp. Vi sparrer sammen rundt hvordan vi finner tall som kan svare på det vi lurer på og hva vi skal sette opp av nye metrikker.

Vi snakket også om at det kan være nyttig med en skjerm på kontoret som viser et dashboard med viktige tall og målinger teamet er opptatt av å følge med på. Det kan føre til gode diskusjoner og gjør at man kan ta pulsen på tjenesten.



Hvordan kan vi jobbe smidig og transparent på tvers av fagområder i datasfæren? 

August – utvikler og dataingeniør i faggruppen Data Engineering

Gruppa jeg var i diskuterte hvordan vi unngår silo-jobbing i verdikjeden fra rådata til innsikt. Det var en del frustrasjon ute å gikk fra forretningsrådgivere og designere, fordi dataingeniørene brukte utrolig lang tid på det som i deres øyne var en enkel oppgave. Det var uklart for dem at det kan være høy kompleksitet i datariggen som gjør det å hente ut et, tilsynelatende, enkelt tall kan være ganske tidkrevende. Det virket som flere hadde erfaring med at det var dårlig kommunikasjon rundt temaet på tvers av fagdisipliner, og at vi bør jobbe med å få en større interesse for hverandres perspektiv.

Jeg føler at det ofte er en mangel på eierskap for prosessen som helhet blant alle roller. Det er lett for en dataingeniør å si seg ferdig med sine oppgaver og forpliktelser så fort datasettet er ferdigbehandlet, på samme måte som at en designer ikke starter sitt innsiktsarbeid før dataen er på plass. Programvareutvikling har beveget seg fra dedikerte frontend- og backend-roller til fullstack og bidrag inn mot innsiktsarbeidet. Dette burde datasfæren dra inspirasjon fra og legge opp til tettere samarbeid på større deler av verdikjeden. Får man til å jobbe smidig på tvers av siloene tror jeg frustrasjonen over hverandre minker og verdien som helhet styrkes. Feedback-loopen fra bruker blir kortere og man vil lettere kunne justere datakildene, transformasjonene og analysen basert på det faktiske behovet.



Hvilke data snakker vi egentlig om?

Jørgen – utvikler i faggruppen Smarte beslutninger

Vi snakket mye om måling av brukermetrikker i smidige team, hvordan gjøre dette på en god måte og hva slags kompetanse det forutsetter. Her må det skilles på behov som kan dekkes i teamet og behov som trenger en større rigg, kanskje i form av dedikerte team. Ellers blir det lett å tenke at datadrevet utvikling krever spesialkompetanse man ikke har – og realistisk sett ikke kommer til å få.

For å iterere på et produkt og velge retning basert på målbare data er det viktig med eierskap innad i teamet. Eierskap til hva som måles og hvorfor det måles, og som følges aktivt opp som del av det daglige arbeidet; gjerne i form av nøkkelresultater (OKR) på brukermetrikker (interaksjon/adopsjon) og domenemetrikker. Dette mener jeg at alle produktteam burde gjøre: Start enkelt og iterer på målingene ettersom behovene konkretiseres.

Ut over dette er det mye som kan gjøres med store datamengder, men det krever dybdekompetanse. Da blir det fort ikke gjennomførbart i fokuserte produktteam og må ikke forveksles med smidig iterasjon, men sees i en større sammenheng i organisasjonen avhengig av hva man ønsker å oppnå.


Ikke la utopien stå i veien for å gjøre det dere kan på teamnivå. Sett opp noen greier med strikk og binders og kom i gang!

Dykk inn i dataen i databasen og finn mer forståelse om brukerne!

Linn – designer i faggruppen UX-nerding

UX-designere (og resten av produktteamet) må åpne opp øynene, se hvilken gullgruve databasen er, og forstå hvilken innsikt den kan gi! Mitt inntrykk er at bransjen begynner å bli gode på å måle klikk på knapper, men at det fortsatt er et stort potensiale i å dykke inn i databasen sammen for å virkelig prøve å forstå brukerne bedre. Både å forstå bruken av produktet og forstå mer om hvem brukerne er. Slik at teamet kan ta bedre valg for produktet basert på god brukerinnsikt.

Det var interessant å høre om utviklere som jobber i data-team, som går dypt inn i å bygge opp datarigger, men som synes det er vanskelig å se hva den konkrete outcomen blir. Hvilke muligheter ligger det i å få en UX-designer på slike team? Hvordan kan en UX-designer bidra med å analysere og forstå organisasjonens behov? Og bidra med å gjøre innsikten mer tilgjengelig for flere ved å visualisere dataen?



Fagkvelden var kun starten på reisen

Kvelden ga rom for mange gode diskusjoner, oppklaringer og refleksjoner, men vi satt igjen med enda flere spørsmål enn svar. Vi skal bli mye bedre på samarbeid om data og analyse på tvers av forretning, design og utvikling. 

Denne kvelden viste noe av jobben som gjenstår for å forstå hverandres perspektiv og arbeidshverdag. For å realisere dette potensialet, må vi jobbe for et tettere samarbeid mellom de som samler og lagrer data, de som analyserer det, og de som trenger innsikten. Det kan både starte i det små i enkelte produktteam, og det kan skje gjennom større initiativ. Vi gleder oss til å fremover høre om team som bruker data mer i beslutninger og om hvordan de helt konkret gjør det i hverdagen!

Data og brukerinnsikt

Hva skal til for å få et godt samarbeid mellom produkteier og designer? Og et godt samarbeid i teamet? 



Å snakke med (og ikke om) den du irriterer deg over 😬🤭🫣

Kommunikasjon er vanskelig! Det kan oppstå uenigheter mellom f.eks. produkteier og designer. Uenigheter kan være bra for å skape de beste løsningene. 

Det er jo en grunn til at vi jobber tverrfaglig — vi skal ta med ulik bagasje og synspunkter inn i produktutviklingen. Vær åpen og ærlig rundt synspunktene dine, og ta tid til å diskutere det som skurrer. Vis og forklar resonnementet, og ikke bare kom med konklusjonen. 

Unngå “paradise hotel”-kommunikasjon. Med dette mener vi: unngå å ta opp problemstillinger med alle andre enn med de som faktisk er uenig med deg. Vi har alle erfaring med at vi etter et møte har vært frustrert og gått til våre “allierte” (f.eks. en i teamet, en venn, personalansvarlig) for å lufte frustrasjonen. Det kan være godt å lette på trykket, men vær bevisst på at det ikke er produktivt i den faktiske diskusjonen, med mindre du får tips til hvordan du bør ta tak i problemstillingen videre.

Hvem går du til når du ønsker å lufte utfordringer i hverdagen? 



Noe som kan hjelpe er å prøve å forstå hvorfor dere egentlig er uenige, og så ta det opp med den det gjelder.

Vårt tips: Unngå “paradise hotel”-kommunikasjon! 

Hvordan samarbeider vi? Del 2

Spotify-modellen rengnes av mange som det beste rammeverket for skalering av smidig praksis. Men bør den anvendes?

Det er verken tankevekkende eller fortryllende å trekke en kanin ved navn organisatorisk smidighet opp av hatten i 2022. Å jobbe etter smidige prinsipper har med årene blitt stadig mer utbredt. Det er ikke lenger kun de små, fleksible selskapene som raskt kan agere og tilpasse seg endrede markedsforhold som anvender en slik arbeidsmetodikk; også større virksomheter ser fordelen med å endre måten de arbeider på, dog med varierende hell.

For store organisasjoner med komplekse prosjekter følger det ofte flere utfordringer tilknyttet å innføre en smidig arbeidsmetodikk, enn det gjør for små og fleksible selskap. Dette har vært en bekjentgjørelse til besvær, og næringslivstopper har tidvis stilt seg rådville til hvordan de skal makte å skalere smidig. Én løsning som har sirkulert på diverse konferanser og møterom de siste årene har vært å se til andre organisasjoner for suksesshistorier, og få har vært mer relevant enn mønstereleven på feltet: Spotify.

Den svenske startupen har vokst seg til verdensherredømme, 10.000 ansatte og 500 millioner brukere på under to tiår. Dette har krevd en enorm oppskalering av organisasjonen, og i 2012 la smidige coacher i Spotify ut et blogginnlegg som proklamerte hvordan en egenutviklet organisasjonsstruktur og arbeidsmetodikk var suksessoppskriften bak å skalere smidig praksis. Dette ble, hendig nok, kjent som Spotify-modellen. I korte trekk er modellen en menneskedrevet, kryssfunksjonell og autonom tilnærming til smidig skalering. Men burde den kopieres?

Kulturen som muliggjør modellen
Før vi ser på organisasjonsstrukturen og arbeidsmetodikken i selskapet — det folk flest anser som selve Spotify-modellen — er det lurt å belyse noen av grunnpilarene som muliggjør Spotifys måte å arbeide smidig på. For det er ikke ene og alene organisasjonsstruktur og arbeidsmetodikk som har gjort at Spotify kan skalere smidig. Man burde heller ta heisen én etasje lenger ned, og forstå at Spotify har inkorporert smidige verdier og prinsipper som fundamentet i alt organisasjonen foretar seg. Dette er prinsipper og verdier Spotify etterlever hver dag, og som alle dets ansatte kan kjenne seg igjen i. Følgelig gjennomsyrer smidig kultur selskapet, og organisatorisk smidighet har derfor blitt en ryggmargsrefleks — ei heller enn en slavisk modell som skal etterfølges.

I fare for å knytte 1.000 helium-ballonger rundt livet og sveve av gårde på uttrykk som smidige prinsipper og verdier, ønsker jeg å trekke frem en konkret handling Spotify foretar seg for å underbygge denne smidige kulturen: de hyller fiasko.

“We aim to make mistakes faster than anyone else”
- Daniel Ek, administrerende direktør i Spotify

Sitatet over er øremerket Spotifys gründer. Den bakenforliggende tanken er at hvis man som selskap skal bygge noe virkelig bra, så er det uunngåelig å gjøre feil på veien. Men hver fiasko er også en læring, sett at dette legges til rette for (eks: post-mortem). Idéen er at selskap som mislykkes raskt, lærer raskt, og derfor forbedrer seg raskt. En strategi som rigger for langvarig suksess. En strategi som fremmer en iterativ arbeidsmetodikk med hyppige læringssykluser. En strategi som er… ganske smidig.

Fire av de sentrale elementene i Spotify-modellen
Spotify-modellen organiserer produktutviklingen i et selskap inn i autonome produktteam på maksimalt 12 ansatte, kalt squads (rett og slett kun et brammende ord for et kryssfunksjonelt team).

Siden fokuset på autonomi er så stort hos Spotify, er fellesnevneren for hver squad at de selv kan bestemme hva de vil lage, hvordan de lager det og hvilket smidig rammeverk de bruker (Scrum, Kanban, etc.) for å komme seg dit. Det finnes åpenbart noen begrensninger på dette, og alle squads besitter en produktsjef som hjelper å sette en strategisk retning for teamet, samt noen kortsiktige mål. De har også en smidig coach for støtte, ettersom smidig arbeidsmetodikk er nytt og uvant for mange av de ansatte. Squads eier sitt eget produktområde, og er ansvarlig for alt fra design og utvikling til lansering og drift av dette. En squad hos Spotify kan f. eks eie og utvikle en algoritme som anbefaler deg låter basert på musikksmaken din, og denne algoritmen er da produktområdet til teamet.

Når flere squads koordinerer med hverandre på det samme funksjonsområdet, danner de en tribe. Et funksjonsområde kan eksempelvis være Spotify Radio, en funksjonalitet i Spotify-appen som automatisk genererer spillelister basert på enhver sang, album, spilleliste eller artist du velger. Skal du like denne auto-genererte spillelisten til Spotify, er det naturlig at den må være noenlunde tilpasset din musikksmak. Derfor er squad’en fra eksempelet over med i en tribe som har Spotify Radio som funksjonsområde; fordi de utvikler algoritmen som anbefaler deg låter basert på din musikksmak. En tribe har også en tribe lead, som skal hjelpe med koordinasjon på tvers av squads og oppfordre til samhandling. Ikke minst må det besørges at hver tribe følger Spotifys overordnede målbilde, at dobbeltarbeid unngås og at ulike tribe leads har tett kommunikasjon hvis funksjonsområder skal sammenkobles.

På tross av at squads er autonome, er det viktig at såkalte spesialister i de ulike teamene (fullstack-utviklere, UX-designere, etc.) er på samme bølgelengde når det kommer til beste praksis for rollen sin. Chapters, myntet som «spesialistene sin familie», skal sørge for at bransjestandarder opprettholdes innenfor hver disiplin. Følgelig har hvert chapter en senior leder som administrerer dette. I selskaper som Spotify er det høy frekvens på utskiftninger i bemanningen, grunnet forfremmelser, omorganisering eller at ansatte søker nye utfordringer andre steder. Det er derfor uhyre viktig å kunne omstille team raskt, dersom en spesialist plutselig forlater en squad. Chapters muliggjør effektiv reallokering av ressurser, ettersom alle ansatte innad i en disiplin sitter på det samme kompetansegrunnlaget.

Medlemmer i ulike squads som brenner for et tema kan forme en guild. Dette er et slags interessefellesskap på tvers av disiplinene, hvor folk som liker alt fra Kotlin og datasikkerhet til hiphop og Fantasy Premier League kan strekke ut en hånd og finne likesinnede. Å delta i en guild er helt frivillig, og de har ingen formell leder. Tanken er at det fremmer synergier på tvers av disiplinene, kan holde de ansatte oppdaterte på fag og skaper et fellesskap innad i selskapet.

På denne måten var Spotify rigget da de i 2012 publiserte blogginnlegget som ga smidig coacher verden over blod på tann. En organisasjonsstruktur som visstnok skal ha lagt grunnsteinene for hvordan de har klart å skalere smidig alle sine år. Så, er å følge denne modellen alt som skal til for at ethvert selskap kan skalere smidig inn i det uendelige?

Trolig ikke.

15-Dec

Today's posts

Compute view logic during render in React

Azure Application Insights using Javascript SDK in Next.js

Dagens designtips

Data og brukerinnsikt

Hvordan samarbeider vi? Del 2

Smidig skalering, Spotify-modellen og det store paradokset