Problemet med gjengivelse av store lister

Anta at De går gjennom en tabell med ti tusen elementer og renderer et li-element for hvert av dem. React oppretter pliktoppfyllende ti tusen DOM-noder, selv om bare et par dusin får plass på skjermen samtidig.

De fleste av nodene er utenfor skjermen og usynlige, men nettleseren må likevel opprette, plassere og vedlikeholde hver eneste av dem.

Nettleseren betaler en reell kostnad for store DOM-trær. Layout, stilberegning og minnebruk øker med antallet noder, så en enorm liste gir tregere første rendering og høyere minnebruk.

Selv enkle interaksjoner kan hakke når motoren må holde styr på og beregne layout på nytt for titusenvis av noder.

Det er ved rulling av en enorm liste brukerne merker problemet best. Nettleseren tegner innholdet på nytt og kan måtte beregne layout på nytt når innholdet flyttes. Med for mange noder faller bildefrekvensen under det som oppleves som jevnt.

Resultatet er hakkete og treg rulling som får grensesnittet til å virke uresponsivt, uansett hvor rask resten av appen er.

De kan bekrefte problemet i Memory-panelet i nettleserens DevTools, som rapporterer antallet DOM-noder på siden. En liste som oppretter tusenvis av noder, blir tydelig synlig her.

Når De ser antallet øke kraftig etter hvert som De renderer flere elementer, får De konkrete bevis på at størrelsen på DOM-en er flaskehalsen.

Virtualisering, noen ganger kalt windowing, renderer bare elementene som for øyeblikket er synlige, pluss en liten buffer, i stedet for hele listen. Når De ruller, mountes elementer som kommer inn i synsfeltet, mens elementer som forlater det, unmountes.

Dette holder den aktive DOM-en liten uansett hvor mange elementer datasettet inneholder, slik at DOM-størrelsen ikke lenger avhenger av størrelsen på datasettet.

Det synlige vinduet beregnes ut fra rulleposisjonen, beholderens høyde og elementhøyden. Ved å dele visningshøyden på elementhøyden får De omtrent hvor mange rader som får plass, og rulleforskyvningen forteller hvilke rader det er.

Biblioteket bruker disse tallene til å avgjøre nøyaktig hvilken del av elementene som skal renderes til enhver tid.

Flere biblioteker implementerer windowing. react-virtualized har mange funksjoner, men er større, react-window er en mindre og mer fokusert omskriving fra samme utvikler, og TanStack Virtual er et moderne headless-alternativ.

For de fleste lister gir react-window en utmerket balanse mellom enkelhet og ytelse, og derfor fokuserer dette kurset på det.

Virtualisering lønner seg når listene er lange, omtrent flere hundre rader eller mer, eller når radene inneholder mange bilder og nestede komponenter. Det er i slike tilfeller DOM-størrelsen faktisk gir ytelsesproblemer.

Uendelige feeder, store datatabeller og chathistorikker er typiske situasjoner der windowing blir nødvendig, ikke bare valgfritt.

For korte lister med noen få dusin enkle elementer tilfører virtualisering kompleksitet uten noen vesentlig fordel. Kostnaden ved absolutt posisjonering og måling kan til og med gi dårligere total ytelse.

Bruk windowing for reelt store datasett. For små datasett er en vanlig map enklere og mer enn rask nok.

Med windowing beholder en liste med hundre tusen elementer bare de få synlige elementene i DOM-en. Første rendering går derfor raskt, minnebruken holder seg lav, og rullingen blir jevn.

De bytter litt økt kompleksitet i oppsettet mot ytelse som ikke lenger avhenger av hvor mye data De har. Dette er hovedløftet ved virtualisering.

Rendering av tusenvis av DOM-noder øker layoutkostnaden, minnebruken og hakkete rulling. Dette kan De bekrefte ved å se på antallet noder i DevTools. Virtualisering renderer bare det synlige vinduet pluss en buffer, slik at DOM-en holdes liten.

react-window er et fokusert og lett alternativ blant react-virtualized og TanStack Virtual. Bruk det for store eller tunge lister, og hopp over det for korte og enkle lister.