Kodėl visi kalba apie Virtual DOM, bet ne visi jį supranta
Kai pradedi dirbti su React, vienas pirmųjų dalykų, kurį išgirsti – tai kažkoks mistinis Virtual DOM. Skamba įspūdingai, atrodo sudėtingai, o iš tikrųjų tai viena protingiausių optimizacijų, kurią frontend bendruomenė sugalvojo. Bet štai problema – daugelis developerių tiesiog priima kaip faktą, kad React „kažkaip greitai veikia” ir nesigilina, kaip tas mechanizmas iš tikrųjų funkcionuoja.
Virtual DOM – tai JavaScript objektų medis, kuris reprezentuoja tikrąjį DOM. Kai tavo komponento state’as pasikeičia, React pirmiausia atnaujina šį virtualų medį, palygina jį su ankstesne versija (šis procesas vadinamas „reconciliation”), ir tik tada atlieka minimalius būtinus pakeitimus tikrajame DOM’e. Skamba paprasta, bet čia slypi daug niuansų.
Realybėje daugelis React aplikacijų kenčia nuo performance problemų ne dėl to, kad Virtual DOM yra lėtas, o dėl to, kad mes, developeriai, verčiame jį atlikti nereikalingą darbą. Kiekvieną kartą, kai komponentas re-renderinasi be reikalo, Virtual DOM turi atlikti visą diff’inimo procesą, net jei rezultatas bus tas pats.
Kada Virtual DOM tampa problemų šaltiniu
Pirmą kartą susiduri su performance problemomis paprastai tada, kai aplikacija auga. Turiu omenyje ne tik kodo kiekį, bet ir duomenų srautus, komponentų hierarchijos gylį, interaktyvių elementų skaičių. Štai keletas klasikinių scenarijų, kur Virtual DOM optimizavimas tampa kritiniu:
Dideli sąrašai ir lentelės. Kai renderini 1000+ elementų sąrašą, kiekvienas parent komponento re-render’as gali sukelti visų child komponentų perskaičiavimą. Net jei duomenys nepasikeitė, React vis tiek turi patikrinti kiekvieną elementą.
Dažni state’o pakeitimai. Realtime aplikacijos, chat’ai, dashboardai su live data – visur, kur state’as keičiasi kas sekundę ar net dažniau, kiekvienas update’as kainuoja.
Gilios komponentų hierarchijos. Kai tavo komponentai įdėti vienas į kitą 10+ lygių giliai, props drilling tampa ne tik kodo organizacijos, bet ir performance problema. Context API čia irgi ne visada išgelbsti.
Praktiškai tai atrodo taip: turi formą su 50 input laukų. Kiekvieną kartą, kai useris įveda raidę į vieną lauką, visas formos komponentas re-renderinasi, o kartu su juo ir visi 50 input komponentų. Jei neoptimizuota, tai gali sukelti jaučiamą lag’ą.
React.memo ir kada jis iš tikrųjų padeda
React.memo yra higher-order komponentas, kuris memorize’ina tavo komponentą. Paprasčiau tariant – jis įsimena paskutinį render’inimo rezultatą ir props, ir jei props nepasikeitė, tiesiog grąžina tą patį rezultatą be re-render’inimo.
Bet čia yra keletas catch’ų. Pirma, React.memo atlieka shallow comparison. Tai reiškia, kad jei perduodi objektą ar masyvą kaip prop, net jei jo turinys nepasikeitė, bet sukūrei naują objekto instanciją – komponentas vis tiek re-renderinsis.
// Blogai - kiekvieną kartą naujas objektas
function ParentComponent() {
return Antra, React.memo turi savo kainą. Kiekvieną kartą React turi palyginti props, o tai irgi užima laiko. Todėl nėra prasmės wrap’inti kiekvieno komponento į React.memo. Tai apsimoka daryti tik tada, kai:
Komponentas renderinasi dažnai su tais pačiais props. Render’inimo logika yra brangi (daug skaičiavimų, sudėtingas JSX). Komponentas yra sąraše ar lentelėje, kur renderinami šimtai instanceų.
Praktiškai, jei tavo komponentas tiesiog atvaizduoja kelis tekstinius laukus, React.memo greičiausiai tik sulėtins, nes props palyginimas kainuos daugiau nei pats render’inimas.
useMemo ir useCallback – ne sidabrinė kulka
Šie hook’ai yra vienas labiausiai piktnaudžiujamų React feature’ų. Matau projektus, kur kiekvienas funkcijos aprašymas wrap’intas į useCallback, o kiekvienas kintamasis – į useMemo. Tai ne tik nereikalinga, bet dažnai net kenkia performance’ui.
useMemo memorize’ina skaičiavimo rezultatą, useCallback – funkciją. Bet pats memorization’as turi overhead’ą – React turi saugoti dependencies array’ų, lyginti juos kiekvieną render’ą, saugoti cache’intus rezultatus.
// Nereikalingas useMemo - paprastas skaičiavimas
const fullName = useMemo(() => {
return firstName + ' ' + lastName;
}, [firstName, lastName]);
// Prasmingas useMemo - brangus skaičiavimas
const sortedAndFilteredData = useMemo(() => {
return data
.filter(item => item.active)
.sort((a, b) => a.name.localeCompare(b.name));
}, [data]);
useCallback dažniausiai reikalingas tik tada, kai funkciją perduodi kaip prop komponentui, kuris yra wrap’intas į React.memo. Kitu atveju naujos funkcijos sukūrimas kiekviename render’e paprastai nekainuoja tiek, kad verta būtų su tuo kovoti.
Štai realus use case’as, kur useCallback būtinas:
const MemoizedList = React.memo(({ items, onItemClick }) => {
return items.map(item => (
Key prop ir kodėl jis svarbesnis nei manai
Key prop’as sąrašuose – tai ne tik būdas atsikratyti console warning’ų. Tai kritinis optimizacijos įrankis, kuris padeda React suprasti, kurie elementai pasikeitė, buvo pridėti ar pašalinti.
Blogiausia, ką gali padaryti – naudoti array index’ą kaip key. Kai sąrašo tvarka keičiasi ar elementai trinami, React nebesugeba teisingai identifikuoti elementų ir gali re-renderinti visą sąrašą arba net prarasti komponento state’ą.
// Blogai - index kaip key
{items.map((item, index) => (
Realus pavyzdys iš praktikos: turėjau todo list’ą, kur naudojau index’us kaip keys. Kai useris ištrindavo elementą iš sąrašo vidurio, visos input’ų reikšmės po to elemento „nušokdavo” į kitą elementą, nes React manė, kad paskutinis elementas buvo ištrintas, o ne tas, kurį useris pažymėjo.
Virtualizacija – kai sąrašai tampa per dideli
Kartais optimizacijos nepakanka. Kai renderini tikrai didelius duomenų kiekius – tūkstančius ar dešimtis tūkstančių elementų – net idealiai optimizuotas Virtual DOM negali padaryti stebuklų. Čia ateina į pagalbą virtualizacija.
Virtualizacijos idėja paprasta: renderini tik tuos elementus, kurie šiuo metu matomi ekrane (plus nedidelį buffer’į). Kai useris scroll’ina, elementai dinamiškai keičiami. Vietoj 10,000 DOM node’ų turi gal 50.
React ekosistemoje populiariausios bibliotekos tam – react-window ir react-virtualized. react-window yra lengvesnė ir paprastesnė, react-virtualized turi daugiau feature’ų, bet yra sunkesnė.
import { FixedSizeList } from 'react-window';
function VirtualizedList({ items }) {
const Row = ({ index, style }) => (
{items[index].name}
);
return (
{Row}
);
}
Virtualizacija turi savo trade-off’us. Prarandamas native browser’io scroll behavior, reikia papildomai tvarkyti accessibility, sudėtingiau implementuoti variable height elementus. Bet kai performance tampa kritinis, tai vienintelis būdas išlaikyti aplikaciją responsive.
Profiling ir kaip rasti tikrąsias problemas
Optimizuoti be matavimo – tai kaip šaudyti tamsoje. React DevTools Profiler yra būtinas įrankis, kurį turi mokėti naudoti. Jis parodo tiksliai, kurie komponentai re-renderinasi, kiek laiko tai užtrunka, ir kas trigger’ino tą re-render’ą.
Kaip naudoti: atidari React DevTools, eini į Profiler tab’ą, paspaudi record, atlieki veiksmus aplikacijoje, kurie lėtai veikia, sustabdai recording’ą. Gauni flame graph’ą, kuris vizualiai parodo, kur laikas praleidžiamas.
Dažniausiai randi kelis komponentus, kurie re-renderinasi šimtus kartų be reikalo. Arba vieną komponentą, kurio render’inimas užtrunka 500ms. Tada jau žinai, kur kasti.
Kitas naudingas įrankis – „Highlight updates when components render” opcija React DevTools. Ji vizualiai parodo, kurie komponentai re-renderinasi realiu laiku. Kartais pakanka tiesiog paspausti mygtukus aplikacijoje ir pamatyti, kaip pusė ekrano mirksi – iš karto aišku, kad kažkas ne taip.
Praktinis patarimas: pradėk profiling’ą nuo production build’o. Development mode’e React daro daug papildomų patikrinimų, kurie sulėtina viską. Tikrasis performance’as matomas tik production’e.
State management ir jo įtaka re-render’ams
Kaip organizuoji state’ą turi didžiulę įtaką tam, kiek komponentų re-renderinasi. Vienas didžiausių newbie mistake’ų – laikyti viską viename dideliame state objekte component’o top level’yje.
// Blogai - visas state'as viename objekte
function App() {
const [state, setState] = useState({
user: {},
posts: [],
comments: [],
ui: { theme: 'dark', sidebarOpen: true }
});
// Bet koks state'o pakeitimas re-renderina visą App
const toggleSidebar = () => {
setState(prev => ({
...prev,
ui: { ...prev.ui, sidebarOpen: !prev.ui.sidebarOpen }
}));
};
}
// Gerai - state'as suskaidytas
function App() {
const [user, setUser] = useState({});
const [posts, setPosts] = useState([]);
const [comments, setComments] = useState([]);
const [theme, setTheme] = useState('dark');
const [sidebarOpen, setSidebarOpen] = useState(true);
// Dabar sidebar toggle'as re-renderina tik tai, kas naudoja sidebarOpen
}
Context API čia irgi gali būti performance killer’is. Kai context value pasikeičia, visi komponentai, kurie naudoja tą context, re-renderinasi. Net jei jiems reikia tik vieno mažo gabaliuko iš to context’o.
Sprendimas – skaidyti context’us į mažesnius. Vietoj vieno didelio AppContext, turėk UserContext, ThemeContext, NotificationsContext. Arba naudok state management bibliotekas kaip Zustand ar Jotai, kurios leidžia subscribe’intis tik į specifines state’o dalis.
Kai optimizacija tampa obsesija ir kaip žinoti, kada sustoti
Yra toks dalykas kaip premature optimization. Galiu pasakyti iš patirties – mačiau projektus, kur kiekvienas komponentas wrap’intas į React.memo, kiekviena funkcija – į useCallback, kiekvienas skaičiavimas – į useMemo. Kodas tampa neskaitomas, o performance’o skirtumas minimalus arba net neigiamas.
Optimizuok tada, kai turi problemą, ne „just in case”. Pradėk nuo paprastos implementacijos, išmatuok performance’ą, ir tik tada, kai matai konkretų bottleneck’ą, pradėk optimizuoti. React yra pakankamai greitas daugumoje use case’ų be jokių papildomų optimizacijų.
Štai praktinė strategija, kurią rekomenduoju:
1. Rašyk švarų, skaitomą kodą. Nesirūpink performance’u iš karto. Teisingai struktūrizuotas kodas vėliau bus lengviau optimizuoti.
2. Matuok. Kai aplikacija pradeda lėtėti, naudok Profiler ir rask tikrąsias problemas. Ne spėliok, matuok.
3. Optimizuok strategiškai. Pradėk nuo didžiausių bottleneck’ų. Dažniausiai 80% performance’o problemų sukelia 20% kodo.
4. Testuok. Po kiekvienos optimizacijos išmatuok rezultatą. Kartais optimizacija nieko neduoda arba net pablogina situaciją.
5. Dokumentuok. Kai naudoji React.memo ar useMemo, palik komentarą kodėl. Po metų nei tu, nei tavo kolegos neatsimins, kodėl tai buvo reikalinga.
Realybėje dauguma React aplikacijų performance problemos kyla ne iš Virtual DOM, o iš blogų architektūrinių sprendimų: per dažnų API call’ų, neoptimizuotų algoritmų, didelių bundle size’ų, neefektyvaus state management’o. Virtual DOM optimizavimas yra svarbus, bet tai tik viena dalis didesnės puzzle’ės.
Taip pat neverta pamiršti, kad hardware’as nuolat gerėja. Optimizacija, kuri šiandien atrodo kritinė, po metų gali būti nereikalinga. Bet tai nereiškia, kad reikia rašyti neefektyvų kodą – tiesiog reikia rasti balansą tarp kodo kokybės, maintainability ir performance’o.
HTML: