Når useLayoutEffect kjører sammenlignet med useEffect

useLayoutEffect kjøres synkront umiddelbart etter at React har brukt DOM-mutasjonene, men før nettleseren har fått mulighet til å tegne disse endringene. Fra nettleserens perspektiv er layouteffekten og DOM-mutasjonene del av den samme uavbrutte, synkrone arbeidsblokken.

useEffect kjøres asynkront etter at nettleseren er ferdig med å tegne. Brukeren ser det oppdaterte brukergrensesnittet først, og deretter kjøres effekten. Dette gjør useEffect mindre forstyrrende for gjengivelsesytelsen, men betyr at synlige endringer som effekten forårsaker, vil føre til en ny tegningssyklus.

Du kan bekrefte forskjellen i tidspunkt ved å logge tidsstempler i begge effektene: legg til console.log('layout', Date.now()) i useLayoutEffect og console.log('passive', Date.now()) i useEffect. I konsollen vil tidsstempelet for layouteffekten alltid være tidligere enn tidsstempelet for den passive effekten, noe som bekrefter kjøringsrekkefølgen.

Hvis en useEffect oppdaterer tilstand som påvirker det visuelle resultatet, ser brukeren to gjengivelser: den første gjengivelsen med utdatert tilstand, og deretter den korrigerte gjengivelsen etter at effekten er kjørt. Dette viser seg som et synlig glimt eller en ny layoutberegning. useLayoutEffect forhindrer dette fordi tilstandsoppdateringene committes før nettleseren tegner noe.

Hvis du kaller setState i en useLayoutEffect, kjører React umiddelbart en ny gjengivelses- og commit-syklus før tegning. Nettleseren tegner bare det endelige resultatet – brukeren ser aldri mellomtilstanden. Dette er det viktigste bruksområdet for useLayoutEffect: mål DOM-en, beregn en ny verdi, oppdater tilstanden og garanter én ren tegning.

Fordi useLayoutEffect kjører synkront før tegning og kan utløse flere gjengivelser, kan overdreven bruk svekke ytelsen. Hvis det synkrone arbeidet er omfattende, blokkerer det nettleseren fra å tegne og fører til synlig hakking. Bruk det bare når du må forhindre et synlig glimt, og bruk useEffect til alt annet.

I React Strict Mode (bare i utviklingsmodus) kjøres både useLayoutEffect og useEffect to ganger per montering. Rekkefølgen er: monter, rydd opp, monter på nytt. Dette gjør det enklere å oppdage effekter som ikke rydder opp på riktig måte. Den doble kjøringen skjer ikke i produksjonsbygg.

Standardvalget bør alltid være useEffect. Bytt bare til useLayoutEffect når du kan observere og gjenskape et problem med synlig flimring eller feil layout. Overdreven bruk av useLayoutEffect blokkerer nettleserens tegneforløp unødvendig og kan svekke den opplevde ytelsen.

useLayoutEffect kan ikke kjøres på serveren fordi det ikke finnes noen DOM eller nettleserbasert tegningssyklus i et servermiljø. Hvis den brukes i en komponent som gjengis på serveren, viser React en advarsel. Løsningen er å hoppe over effekten betinget: sjekk typeof window !== 'undefined', eller bytt til useEffect for SSR-kompatibel kode.

Spør deg selv: "Endrer denne effekten noe som brukeren vil se ved den aller første tegningen?" Hvis svaret er ja, bruker du useLayoutEffect for å forhindre et glimt. Hvis svaret er nei – for datainnhenting, abonnementer, analyse, logging og de fleste andre bivirkninger – bruker du useEffect. Dette beslutningsrammeverket dekker de fleste tilfeller i praksis.

useLayoutEffect kjører i den samme synkrone arbeidsblokken som DOM-mutasjonene. React kan ikke behandle annet arbeid (som å svare på brukerhendelser) mens en useLayoutEffect kjører. Derfor må den være rask og målrettet. Langvarig synkron kode i useLayoutEffect forsinker nettleserens visning direkte.

useLayoutEffect er synkron og kjøres før nettleseren tegner, noe som gjør den egnet for DOM-måling og visuelle korrigeringer. useEffect kjøres etter tegning og er det riktige valget for datainnhenting, abonnementer og de fleste bivirkninger. Velg useEffect som standard, og bytt bare når visuell flimring bekrefter at useLayoutEffect er nødvendig. Unngå den i SSR uten beskyttelser.