React içinde Virtual DOM’un ne olduğu, gerçek DOM ile nasıl bir fark yarattığı ve güncellemelerde diff algoritmasının nasıl çalıştığı konusunda kafam karıştı. Render sürecinde bileşenlerin state değiştiğinde ne kadar kısmın yeniden çizildiğini ölçmek istiyorum. Bu mekanizmanın performansa etkisini daha iyi kavrayabilmek için temel adımları ve örnek akışı anlatır mısınız? Sizce en kritik nokta nedir?
React'te Virtual DOM nasıl çalışır ve performansa etkisi nedir?
👁️ 23 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
J’ai eu l’occasion de creuser le Virtual DOM quand on a migré un tableau de 10 000 lignes d’un rendu serveur vers un composant React purement client. Au départ, je pensais que chaque changement d’état déclenchait un repaint complet du DOM, mais le profiling a rapidement montré le contraire : dès que `setState` est appelé, React crée un **nouveau arbre Virtual DOM** en mémoire, puis il le compare avec l’arbre précédent grâce à l’algorithme de **diff** (reconciliation). Le diff se base sur trois règles simples – même type de composant, même clé, même position – et ne parcourt que les branches affectées. Ainsi, même si le composant parent change, les sous‑arbres qui n’ont pas de différence de clés restent intacts et aucune mise à jour réelle n’est envoyée au navigateur.
Dans mon projet, j’ai instrumenté le rendu avec le hook `useEffect(() => console.log('rendered'), [])` et le devtool React Profiler. J’ai découvert que, lorsqu’on modifiait uniquement un champ de recherche, React ne reconstruit que le sous‑composant de la ligne filtrée ; le reste du tableau conserve son instance du Virtual DOM et ne touche pas le DOM réel. La mesure du temps de “commit” (phase où les changements sont appliqués au réel DOM) était donc de l’ordre de quelques millisecondes, contre plusieurs dizaines de millisecondes avant la migration. Cela confirme que le **goulot critique** n’est pas le diff en soi, mais la **mise à jour du DOM réel** qui reste très coûteuse.
Le point le plus critique à surveiller, c’est donc la granularité des composants et l’utilisation de **clés stables**. Si chaque ligne du tableau possède une clé unique (`key={row.id}`), React peut ré‑utiliser les instances existantes et éviter de recréer tout le sous‑arbre. En pratique, j’ai aussi ajouté `React.memo` sur les lignes pour empêcher des re‑renders inutiles lorsqu’aucune prop ne change. Avec ces deux optimisations – clés cohérentes et mémoïsation – le Virtual DOM devient presque transparent : on voit la différence de performance sans devoir toucher au code de diff, et le profiling reste simple à interpréter.