Pourquoi le concept de DOM virtuel de React est-il considéré comme plus performant que le model checking sale ?

Question

J'ai vu un React conférence sur le développement à ( Pete Hunt : React : Repenser les meilleures pratiques -- JSConf EU 2013 ) et l'orateur a mentionné que la vérification du modèle peut être lente. Mais le calcul de la différence entre les DOM virtuels n'est-il pas en fait encore moins performant puisque le DOM virtuel, dans la plupart des cas, devrait être plus grand que le modèle ?

J'aime vraiment la puissance potentielle du DOM virtuel (en particulier le rendu côté serveur) mais j'aimerais connaître tous les avantages et les inconvénients.

Answer 1

Je suis l'auteur principal d'un domaine virtuel donc je pourrais être en mesure de répondre à vos questions. Il y a en fait 2 problèmes qui doivent être résolus ici

1. Quand dois-je refaire le rendu ? Réponse : Lorsque j'observe que les données sont sales.
2. Comment refaire un rendu efficace ? Réponse : Utilisation d'un DOM virtuel pour générer un patch DOM réel

Dans React, chacun de vos composants a un état. Cet état est comme un observable que vous pourriez trouver dans knockout ou d'autres bibliothèques de style MVVM. Essentiellement, React sait quand de refaire le rendu de la scène car il est capable d'observer quand ces données changent. Le contrôle d'état est plus lent que les observables car vous devez interroger les données à intervalles réguliers et vérifier toutes les valeurs de la structure de données de manière récursive. En comparaison, la définition d'une valeur sur l'état signalera à un auditeur qu'un certain état a changé, de sorte que React peut simplement écouter les événements de changement sur l'état et mettre en file d'attente le nouveau rendu.

Le DOM virtuel est utilisé pour un nouveau rendu efficace du DOM. Cela n'est pas vraiment lié au dirty checking de vos données. Vous pouvez effectuer un nouveau rendu en utilisant un DOM virtuel avec ou sans dirty checking. Vous avez raison de dire qu'il y a une certaine surcharge dans le calcul de la différence entre deux arbres virtuels, mais la différence du DOM virtuel concerne la compréhension de ce qui doit être mis à jour dans le DOM et non pas le fait que vos données aient changé ou non. En fait, l'algorithme diff est un vérificateur sale lui-même mais il est utilisé pour voir si le DOM est sale à la place.

Notre objectif est de ne rendre à nouveau l'arbre virtuel que lorsque l'état change. Ainsi, l'utilisation d'un observable pour vérifier si l'état a changé est un moyen efficace d'éviter les rendus inutiles, qui entraîneraient de nombreuses différences inutiles dans l'arbre. Si rien n'a changé, nous ne faisons rien.

Un DOM virtuel est intéressant parce qu'il nous permet d'écrire notre code comme si nous faisions un nouveau rendu de la scène entière. Dans les coulisses, nous voulons calculer une opération de patch qui met à jour le DOM pour qu'il ressemble à ce que nous attendons. Ainsi, alors que l'algorithme diff/patch du DOM virtuel n'est probablement pas la solution optimale il nous donne un moyen très agréable d'exprimer nos applications. Il nous suffit de déclarer exactement ce que nous voulons et React/virtual-dom se débrouillera pour que votre scène ressemble à ceci. Nous n'avons pas besoin de manipuler manuellement le DOM ou de nous embrouiller avec l'état précédent du DOM. Nous n'avons pas non plus à refaire le rendu de toute la scène, ce qui pourrait être beaucoup moins efficace que de Parcheandola faire.

Answer 2

J'ai récemment lu un article détaillé sur l'algorithme diff de React ici : http://calendar.perfplanet.com/2013/diff/ . D'après ce que je comprends, ce qui rend React rapide est :

• Opérations de lecture/écriture de DOM par lots.
• Mise à jour efficace de la sous-arborescence uniquement.

Par rapport au dirty-check, les principales différences sont les suivantes :

1. Vérification du modèle : Le composant React est explicitement défini comme sale chaque fois que setState est appelé, donc il n'y a pas de comparaison (des données) nécessaire ici. Pour le dirty-checking, la comparaison (des modèles) se fait toujours à chaque boucle de digest.

2. Mise à jour du DOM : Les opérations DOM sont très coûteuses car la modification du DOM va également appliquer et calculer les styles CSS, les mises en page. Le temps économisé sur les modifications inutiles du DOM peut être plus long que le temps passé à modifier le DOM virtuel.

Le deuxième point est encore plus important pour les modèles non triviaux, comme ceux qui comportent un grand nombre de champs ou de listes. Un changement de champ d'un modèle complexe n'entraînera que les opérations nécessaires pour les éléments DOM impliquant ce champ, au lieu de la vue/du modèle entier.

Answer 3

J'aime vraiment la puissance potentielle du DOM virtuel (en particulier le rendu côté serveur) mais j'aimerais connaître tous les avantages et les inconvénients.

-- OP

React n'est pas la seule bibliothèque de manipulation du DOM. Je vous encourage à comprendre les alternatives en lisant ceci article de Auth0 qui comprend une explication détaillée et des points de référence. Je vais souligner ici leurs avantages et inconvénients, comme vous l'avez demandé :

Le DOM virtuel de React.js

PROS

• Algorithme de "diffing" rapide et efficace
• Frontaux multiples (JSX, hyperscript)
• Suffisamment léger pour fonctionner sur des appareils mobiles
• Beaucoup de traction et de partage de l'esprit
• Peut être utilisé sans React (c'est-à-dire comme un moteur indépendant)

CONS

• Copie complète en mémoire du DOM (utilisation plus importante de la mémoire)
• Aucune différenciation entre les éléments statiques et dynamiques

---

Glimmer de Ember.js

PROS

• Algorithme de différenciation rapide et efficace
• Différenciation entre éléments statiques et dynamiques
• 100% compatible avec l'API d'Ember (vous bénéficiez des avantages sans avoir à effectuer de mises à jour majeures de votre code existant)
• Représentation légère en mémoire du DOM

CONS

• Destiné à être utilisé uniquement dans Ember
• Un seul frontend disponible

---

DOM incrémentiel

PROS

• Utilisation réduite de la mémoire
• API simple
• S'intègre facilement à de nombreux frontaux et frameworks (conçu dès le départ comme un moteur de modèles).

CONS

• Pas aussi rapide que d'autres bibliothèques (ceci est discutable, voir les benchmarks ci-dessous)
• Moins d'attention et d'utilisation par la communauté

Answer 4

Voici un commentaire de Sebastian Markbåge, membre de l'équipe React, qui apporte un éclairage :

React effectue la différenciation sur la sortie (qui est un format sérialisable connu, les attributs DOM). Cela signifie que les données sources peuvent être de n'importe quel format. Il peut s'agir de structures de données immuables et d'états à l'intérieur de fermetures.

Le modèle Angular ne préserve pas la transparence référentielle et est donc intrinsèquement mutable. Vous mutez le modèle existant pour suivre les changements. Que faire si votre source de données est constituée de données immuables ou d'une nouvelle structure de données à chaque fois (comme une réponse JSON) ?

Dirty checking et Object.observe ne fonctionnent pas sur l'état de la portée de la fermeture.

Ces deux éléments sont évidemment très limitatifs pour les modèles fonctionnels.

En outre, lorsque la complexité de votre modèle augmente, il devient de plus en plus coûteux d'effectuer un suivi de la saleté. Cependant, si vous ne faites que de la différenciation sur l'arbre visuel, comme React, alors il ne se développe pas autant puisque la quantité de données que vous êtes en mesure de montrer à l'écran à un moment donné est limitée par les interfaces utilisateur. Le lien de Pete ci-dessus couvre davantage les avantages de la perfusion.

https://news.ycombinator.com/item?id=6937668

Answer 5

Dans React, chacun de vos composants a un état. Cet état est comme un observable que vous pourriez trouver dans knockout ou d'autres bibliothèques de style MVVM. Essentiellement, React sait quand il faut refaire la scène parce qu'il est capable d'observer quand ces données changent. Le Dirty Checking est plus lent que les observables car vous devez interroger les données à un intervalle régulier et vérifier toutes les valeurs de la structure de données de manière récursive. En comparaison, la définition d'une valeur sur l'état signalera à un auditeur qu'un certain état a changé, de sorte que React peut simplement écouter les événements de changement sur l'état et mettre en file d'attente le re-rendu.Le DOM virtuel est utilisé pour un re-rendu efficace du DOM. Cela n'est pas vraiment lié à la vérification de vos données. Vous pouvez effectuer un nouveau rendu en utilisant un DOM virtuel avec ou sans dirty checking. Vous avez raison de dire qu'il y a une certaine surcharge dans le calcul de la différence entre deux arbres virtuels, mais la différence du DOM virtuel consiste à comprendre ce qui doit être mis à jour dans le DOM et non pas si vos données ont changé ou non. En fait, l'algorithme diff est lui-même un "dirty checker" mais il est plutôt utilisé pour voir si le DOM est sale.

Notre objectif est de ne rendre à nouveau l'arbre virtuel que lorsque l'état change. Ainsi, l'utilisation d'un observable pour vérifier si l'état a changé est un moyen efficace d'éviter les réexpositions inutiles, qui entraîneraient de nombreuses différences inutiles dans l'arbre. Si rien n'a changé, nous ne faisons rien.