Evitare layout thrashing e sfarfallii visivi

Il layout thrashing si verifica quando JavaScript alterna la lettura delle proprietà del DOM e la scrittura nel DOM all'interno di un ciclo. Ogni lettura successiva a una scrittura forza il browser a ricalcolare il layout in modo sincrono per restituire un valore accurato. Questo può trasformare un singolo calcolo del layout in decine di calcoli, danneggiando gravemente le prestazioni.

React raggruppa tutte le chiamate a setState eseguite nei gestori degli eventi e negli effetti in un unico nuovo rendering. Questo batching naturale impedisce il pattern lettura-scrittura-lettura che causa il thrashing all'interno di un singolo ciclo di rendering. In React 18, il batching si estende anche alle callback asincrone e alle Promise, riducendo il layout thrashing causato dagli aggiornamenti di stato concorrenti.

Lo sfarfallio si verifica quando un useEffect legge il DOM, aggiorna lo stato, attiva un nuovo rendering e il browser esegue il paint due volte: una volta con lo stato iniziale e una volta con quello corretto. Il primo paint appare brevemente prima di essere sostituito. Il fenomeno è più evidente negli effetti che modificano proprietà di layout come altezza, larghezza o posizione.

Apra Chrome DevTools, acceda alla scheda Rendering tramite il menu con i tre puntini, nella sezione Altri strumenti, e abiliti "Paint flashing". Le aree che vengono ridisegnate vengono evidenziate in verde. Se vede un componente sfarfallare al primo rendering e poi ridisegnarsi immediatamente con un layout diverso, ciò conferma la presenza di un doppio paint causato da un aggiornamento dello stato gestito da useEffect.

Sposti le letture del DOM e i conseguenti aggiornamenti dello stato da useEffect a useLayoutEffect. La stessa misurazione e lo stesso aggiornamento dello stato avvengono ora in modo sincrono prima del paint; React esegue nuovamente il rendering e il commit nello stesso passaggio, quindi il browser esegue il paint solo dello stato finale corretto. Lo sfarfallio verde in DevTools scompare.

Il pattern per evitare lo sfarfallio è il seguente: leggere il DOM in useLayoutEffect, chiamare setState con la misurazione, eseguire nuovamente il rendering in modo sincrono, applicare tramite commit il DOM corretto e lasciare che il browser esegua un solo paint con il risultato finale. Questo è il pattern standard per il posizionamento dei tooltip, gli offset delle intestazioni sticky e la configurazione delle animazioni.

La grande maggioranza degli effetti deve essere inserita in useEffect: recupero dei dati (lo sfarfallio durante il caricamento è accettabile e previsto), sottoscrizioni a eventi o stream, logging e analisi, timer e qualsiasi effetto che non influisca immediatamente sul layout visibile. Usare useLayoutEffect anche quando sarebbe sufficiente useEffect è un anti-pattern che penalizza le prestazioni.

Riservi useLayoutEffect alle misurazioni del DOM che influiscono sull'output visivo: posizioni dei tooltip, logica basata sulle dimensioni degli elementi, ripristino della posizione di scorrimento e configurazione di animazioni che leggono le dimensioni iniziali. Un sintomo evidente che indica la necessità di passare a questo hook è la comparsa di uno sfarfallio visibile, della durata di un frame, con un layout errato al primo rendering.

I due hook hanno firme identiche: useLayoutEffect(callback, deps) e useEffect(callback, deps). L'unica differenza riguarda il momento in cui viene eseguito il callback. Nel codice è possibile passare dall'uno all'altro modificando una sola parola. Inizi con useEffect e passi a useLayoutEffect solo dopo aver confermato la presenza dello sfarfallio.

È valido e comune usare entrambi gli hook nello stesso componente per gestire responsabilità diverse. Per esempio, un componente che visualizza un grafico può usare useLayoutEffect per misurare la larghezza del contenitore e impostare il viewBox SVG in modo sincrono, quindi usare useEffect per recuperare asincronamente i dati del grafico. Ogni hook gestisce la responsabilità per la quale la tempistica è importante.

Oltre alla visualizzazione dei paint in DevTools, è possibile aggiungere un contatore nella console all'interno del componente per contare i rendering. Se un componente registra "render" due volte al primo montaggio, una volta con lo stato iniziale e una volta con la misurazione corretta, si è in presenza di uno scenario con doppio paint. Spostando la misurazione in useLayoutEffect, dopo il montaggio dovrebbe essere registrato un solo rendering (a eccezione del doppio rendering dovuto a Strict Mode).

Quale scenario rappresenta il motivo corretto per usare useLayoutEffect invece di useEffect?

Il layout thrash deriva dall'alternanza tra letture e scritture del DOM. Il batching di React ne previene la maggior parte durante i rendering. Lo sfarfallio si verifica quando useEffect misura il DOM e aggiorna lo stato, causando due paint. Per correggere lo sfarfallio, sposti le misurazioni del DOM in useLayoutEffect. Per tutto il resto, usi useEffect per impostazione predefinita: recupero dei dati, sottoscrizioni, logging e timer.