Comment utiliser le DOM virtuel React

Cette fois, je vais vous montrer comment utiliser le DOM virtuel React et quelles sont les précautions lors de l'utilisation du DOM virtuel React. Voici des cas pratiques, jetons un coup d'œil.

Dans le développement Web, les modifications des données doivent être reflétées dans l'interface utilisateur en temps réel. À ce stade, le DOM doit être exploité. Cependant, les opérations DOM complexes ou fréquentes sont généralement à l'origine de goulots d'étranglement en termes de performances. C'est pour cette raison que React introduit le mécanisme du DOM virtuel (Virtual DOM).

1. Qu'est-ce que le DOM virtuel ?

Dans React, le résultat de l'exécution du rendu n'est pas un véritable nœud DOM, mais un objet JavaScript léger, que nous appelons DOM virtuel.

Le DOM virtuel est un point fort de React, avec un traitement par lots et un algorithme Diff efficace. Cela nous permet de « rafraîchir » la page entière à tout moment sans nous soucier des problèmes de performances, et le DOM virtuel garantit que seules les opérations DOM réelles sont effectuées sur les parties réellement modifiées de l'interface. Dans le développement réel, vous n'avez fondamentalement pas besoin de vous soucier du fonctionnement du DOM virtuel, mais comprendre son mécanisme de fonctionnement vous aidera non seulement à mieux comprendre le cycle de vie des composants React, mais sera également d'une grande utilité. aider à optimiser davantage les programmes React.

2. DOM virtuel VS exploitant directement le DOM natif ?

S'il n'y a pas de DOM virtuel, réinitialisez simplement innerHTML directement. Cette opération est raisonnable lorsque toutes les données d'une grande liste ont changé. Cependant, lorsqu'une seule ligne de données change, elle nécessite également de réinitialiser tout l'innerHTML, ce qui entraîne évidemment beaucoup de gaspillage.

Comparez le processus de redessin de innerHTML et Virtual DOM comme suit :

innerHTML : restituer la chaîne HTML + recréer tous les éléments du DOM

Virtual DOM : rendre Virtual DOM + diff + nécessaire Mise à jour du DOM

Par rapport au fonctionnement du DOM, le calcul js est très bon marché. Le rendu + diff du DOM virtuel est évidemment plus lent que le rendu des chaînes HTML, mais il s'agit toujours d'un calcul pur au niveau js, qui est encore beaucoup moins cher que les opérations DOM ultérieures. Bien sûr, quelqu'un a fait une vérification et a dit que les performances de React ne sont pas aussi bonnes que l'exploitation directe du vrai DOM. Le code est le suivant :

function Raw() {
  var data = _buildData(),
    html = "";
  ...
  for(var i=0; i<data.length; i++) {
    var render = template;
    render = render.replace("{{className}}", "");
    render = render.replace("{{label}}", data[i].label);
    html += render;
  }
  ...
  container.innerHTML = html;
  ...
}

Dans ce cas de test, bien qu'une chaîne contienne 1000. Les balises sont construites et ajoutées à l'arborescence DOM, mais une seule opération DOM a été effectuée. Cependant, dans le processus de développement actuel, ces 1 000 mises à jour d'éléments peuvent être distribuées en 20 blocs logiques, chaque bloc logique contient 50 éléments. Lorsque la page doit être mise à jour, l'arborescence DOM sera mise à jour approximativement. devenir Cela devient le format suivant :

function Raw() {
  var data = _buildData(), 
    html = ""; 
  ... 
  for(var i=0; i<data.length; i++) { 
    var render = template; 
    render = render.replace("{{className}}", ""); 
    render = render.replace("{{label}}", data[i].label); 
    html += render; 
    if(!(i % 50)) {
      container.innerHTML = html;
    }
  } 
  ... 
}

De ce point de vue, les performances de React sont bien meilleures que les opérations natives du DOM.

De plus, DOM n'appartient pas du tout à Javascript (il n'existe pas non plus dans les moteurs Javascript). Javascript est en fait un moteur très indépendant. DOM est en fait un ensemble d'API introduites par le navigateur qui permettent à Javascript d'exploiter des documents HTML. À l’ère de la compilation juste à temps, la surcharge liée à l’appel de DOM est très élevée. L'exécution de Virtual DOM se fait entièrement dans le moteur Javascript, et il n'y a aucune surcharge de ce type.

React.js présente de grands avantages en termes de performances par rapport à la manipulation directe du DOM natif, en grande partie grâce au traitement par lots et aux différences du DOM virtuel. Le traitement par lots collecte toutes les opérations DOM et les soumet immédiatement au vrai DOM. La complexité temporelle de l'algorithme diff a également été réduite de O(n^3) de l'algorithme Diff standard à O(n). Je laisse cela au prochain article du blog.

3. DOM virtuel VS MVVM ?

Par rapport à React, d'autres frameworks MVVM tels que Angular, Knockout, Vue et Avalon utilisent tous la liaison de données : via des objets Directive/Binding, observez les changements de données et conserve la référence à l'élément DOM réel et effectue les opérations correspondantes lorsque les données changent. La vérification des modifications de MVVM se fait au niveau des données, tandis que la vérification de React se fait au niveau de la structure DOM. Les performances de MVVM diffèrent également en fonction du principe de mise en œuvre de la détection des changements : le contrôle sale d'Angular fait que tout changement a un coût fixe de O (nombre d'observateurs) ; Knockout/Vue/Avalon utilisent tous la collection de dépendances, à la fois au niveau js et au niveau DOM ; Oui O (changement) :

1. Vérification incorrecte : résumé de la portée + mise à jour DOM nécessaire

2. Collection de dépendances : collecte à nouveau des dépendances + mise à jour DOM nécessaire

Comme vous pouvez le constater, la chose la plus inefficace à propos d'Angular est que tout petit changement a un coût en performances lié au nombre d'observateurs. mais! Lorsque toutes les données changent, Angular ne souffre pas. La collecte des dépendances nécessite une nouvelle collecte des dépendances lors de l'initialisation et des modifications des données. Ce coût peut être presque ignoré lorsqu'un petit nombre de mises à jour est effectué, mais il entraînera également une certaine consommation lorsque la quantité de données est importante.

Lorsque MVVM affiche une liste, puisque chaque ligne a sa propre portée de données, chaque ligne a généralement une instance ViewModel correspondante, ou un objet "portée qui utilise l'héritage de prototype" légèrement plus léger, mais il y a un prix. Par conséquent, l'initialisation du rendu de la liste MVVM est presque garantie d'être plus lente que React, car la création d'instances ViewModel/scope est beaucoup plus coûteuse que Virtual DOM. Un problème courant pour toutes les implémentations MVVM ici est de savoir comment réutiliser efficacement les instances ViewModel et les éléments DOM déjà créés lorsque la source de données pour le rendu de la liste change, en particulier lorsque les données sont un tout nouvel objet. Sans aucune optimisation de réutilisation, puisque les données sont "nouvelles", MVVM doit en fait détruire toutes les instances précédentes, recréer toutes les instances et enfin restituer à nouveau ! C'est pourquoi les implémentations angulaires/knockout liées dans le titre sont relativement lentes. En revanche, puisque la vérification des modifications de React se fait au niveau de la structure DOM, même s'il s'agit de données toutes nouvelles, tant que le résultat final du rendu n'a pas changé, il n'est pas nécessaire de faire un travail inutile.

Angular et Vue fournissent tous deux des mécanismes d'optimisation pour le redessinage des listes, qui sont des "indices" du framework sur la manière de réutiliser efficacement les instances et les éléments DOM. Par exemple, le même objet dans la base de données deviendra des objets différents dans deux appels d'API front-end, mais ils auront toujours le même UID. À ce stade, vous pouvez demander au suivi par uid de faire savoir à Angular que les deux objets sont en réalité les mêmes données. Ensuite, les instances et éléments DOM correspondant aux données d'origine peuvent être réutilisés, et seules les parties modifiées doivent être mises à jour. Ou, vous pouvez également suivre directement par $index pour effectuer une « réutilisation sur place » : réutilisation directement en fonction de la position dans le tableau. Dans l'exemple donné dans la question, si l'implémentation angulaire ajoute un suivi par $index, le redessin ultérieur ne sera pas beaucoup plus lent que React. Même dans le test dbmonster, Angular et Vue sont plus rapides que React après avoir utilisé track by $index: dbmon (notez que la version par défaut d'Angular n'est pas optimisée, la version optimisée est ci-dessous)

En comparant les performances, il est nécessaire de diviser Comprendre les différentes occasions de rendu initial, de petite mise à jour de données et de grande mise à jour de données. Le DOM virtuel, la vérification sale MVVM, la collecte de données MVVM ont des performances différentes et des exigences d'optimisation différentes à différentes occasions. Afin d'améliorer les performances des petites mises à jour de données, Virtual DOM a également besoin d'une optimisation ciblée, telle que ShouldComponentUpdate ou des données immuables.

1. Rendu initial : DOM virtuel > Dirty Check >= Collection de dépendances

2. Petite mise à jour des données : Collection de dépendances>> Optimisation > Dirty Check (ne peut pas être optimisé) > Virtual DOM Aucune optimisation

3. Mises à jour de données volumineuses : Dirty Check + Optimisation > = Collecte de dépendances + Optimisation > Aucune optimisation requise)>> MVVM sans optimisation

4. (Ce paragraphe s'appuie sur les réponses connexes de Zhihu)

4. Incompréhension du DOM virtuel React ?

React n'a jamais dit "React est plus rapide que la manipulation native du DOM". React nous garantit qu'il peut toujours nous fournir des performances décentes sans optimisation manuelle.

React masque les opérations DOM sous-jacentes et peut décrire notre objectif de manière plus déclarative, rendant le code plus facile à maintenir. Ce qui suit est basé sur la réponse de Zhihu : aucun framework ne peut optimiser les opérations DOM plus rapidement que les opérations purement manuelles, car la couche d'opérations DOM du framework doit gérer toutes les opérations qui peuvent être générées par l'API de couche supérieure et sa mise en œuvre. doit être universelle. Pour n’importe quel benchmark, je peux écrire des optimisations manuelles plus rapides que n’importe quel framework, mais à quoi ça sert ? Lorsque vous créez une application pratique, effectuez-vous une optimisation manuelle pour chaque endroit ? Pour des raisons de maintenabilité, cela n'est évidemment pas possible.

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !

Lecture recommandée :

Téléchargement d'images avec le code backend dans le mini-programme WeChat


Pratique pratique du téléchargement d'images dans WeChat mini programme Analyse de cas


Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!