Pourquoi le concept de Virtual DOM de React est-il dit plus performant que la vérification de modèle sale?
J'ai vu une conversation React dev à ( Pete Hunt: React: repenser les meilleures pratiques - JSConf EU 201 ) et le conférencier a mentionné que la vérification du modèle peut être lente . Mais le calcul du diff entre les DOM virtuels n'est-il pas encore moins performant puisque le DOM virtuel, dans la plupart des cas, devrait être plus grand que le modèle?
J'aime beaucoup 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.
Je suis l'auteur principal d'un module virtual-dom , je pourrais donc peut-être répondre à vos questions. Il y a en fait 2 problèmes qui doivent être résolus ici
- Quand dois-je effectuer un nouveau rendu? Réponse: Lorsque j'observe que les données sont sales.
- Comment restituer efficacement le rendu? Réponse: Utiliser un DOM virtuel pour générer un correctif DOM réel
Dans React, chacun de vos composants a un état. Cet état est comparable à un état observable que vous pouvez trouver dans les bibliothèques knockout ou autres bibliothèques de style MVVM. Essentiellement, React sait à quel moment restituer la scène, car il est capable de voir à quel moment ces données changent. La vérification sale est plus lente 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. À titre de comparaison, définir une valeur sur l'état signalera à un auditeur que certains états ont changé. Ainsi, React peut simplement écouter les événements de modification de l'état et mettre en file d'attente le rendu.
Le DOM virtuel est utilisé pour rendre efficacement le rendu du DOM. Ce n'est pas vraiment lié à la vérification incorrecte de vos données. Vous pouvez effectuer un nouveau rendu à l'aide d'un DOM virtuel avec ou sans vérification incorrecte. Vous avez raison de dire qu'il y a une surcharge dans le calcul du diff entre deux arbres virtuels, mais le diff du DOM virtuel consiste à comprendre ce qui doit être mis à jour dans le DOM et non à déterminer si vos données ont changé ou non. En fait, l'algorithme diff est un vérificateur sale mais il est utilisé pour voir si le DOM est plutôt sale.
Nous visons à rendre l’arborescence virtuelle uniquement lorsque l’état change. Donc, utiliser un observable pour vérifier si l'état a changé est un moyen efficace d'éviter les rediffusions inutiles, ce qui causerait beaucoup de différences d'arborescence inutiles. Si rien n'a changé, nous ne faisons rien.
Un DOM virtuel, c’est bien parce qu’il nous permet d’écrire notre code comme si nous rediffusions l’ensemble de la scène. En coulisse, nous souhaitons calculer une opération de correction qui met à jour le DOM afin qu'il corresponde à vos attentes. Ainsi, bien que l’algorithme de diff/patch du DOM virtuel ne soit probablement pas la solution optimale , il nous offre un moyen très agréable d’exprimer nos applications. Nous déclarons simplement ce que nous voulons et React/virtual-dom trouvera comment rendre votre scène semblable à celle-ci. Nous n'avons pas à faire de manipulation manuelle du DOM ni à nous embrouiller à propos de l'état précédent du DOM. Nous n'avons pas non plus besoin de refaire le rendu de la scène entière, ce qui pourrait être beaucoup moins efficace que de la corriger.
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 j'ai compris, ce qui rend React rapide, c'est:
- Opérations de lecture/écriture DOM par lots.
- Mise à jour efficace du sous-arbre uniquement.
Par rapport au contrôle de contrôle, les principales différences à l’OMI sont les suivantes:
Le modèle sale-vérifiant : le composant React est défini explicitement comme sale à chaque fois que
setStateest appelé, il n'y a donc aucune comparaison possible ( des données) nécessaires ici. Pour le "dirty-checking", la comparaison (des modèles) a toujours lieu à chaque boucle de digestion.Mise à jour du DOM : les opérations du DOM coûtent très cher car la modification du DOM s'appliquera et calculera également les styles CSS, les layouts. Le temps économisé par une modification inutile du DOM peut être plus long que le temps consacré à la différenciation du DOM virtuel.
Le deuxième point est encore plus important pour les modèles non triviaux, tels que ceux comportant un grand nombre de champs ou une grande liste. Un changement de champ d'un modèle complexe entraînera uniquement les opérations nécessaires pour les éléments DOM impliquant ce champ, au lieu de la vue/du modèle entier.
J'aime beaucoup 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 DOM. Je vous encourage à comprendre les alternatives en lisant ceci article de Auth qui inclut une explication détaillée et des points de repère. Je vais souligner ici leurs avantages et inconvénients, comme vous l'avez demandé:
Le DOM virtuel de React.js
AVANTAGES
- Algorithme "diffing" rapide et efficace
- Plusieurs interfaces (JSX, hyperscript)
- Assez léger pour fonctionner sur les appareils mobiles
- Beaucoup de traction et de mentalité
- Peut être utilisé sans React (c'est-à-dire en tant que moteur indépendant)
LES INCONVÉNIENTS
- Copie complète en mémoire du DOM (utilisation plus importante de la mémoire)
- Pas de différenciation entre les éléments statiques et dynamiques
Ember.js 'Glimmer
AVANTAGES
- Algorithme de diffing rapide et efficace
- Différenciation entre éléments statiques et dynamiques
- 100% compatible avec l'API Ember (vous bénéficiez des avantages sans mises à jour majeures de votre code existant)
- Représentation légère en mémoire du DOM
LES INCONVÉNIENTS
- Destiné à être utilisé uniquement dans Ember
- Une seule interface disponible
DOM incrémental
AVANTAGES
- Utilisation réduite de la mémoire
- API simple
- S'intègre facilement à de nombreux frontaux et frameworks (conçu comme un moteur de template depuis le début)
LES INCONVÉNIENTS
- Pas aussi vite que d'autres bibliothèques (c'est discutable, voir les points de repère ci-dessous)
- Moins de partage d'esprit et d'utilisation par la communauté
Voici un commentaire de Sebastian Markbåge, membre de l’équipe de React - qui donne un éclairage:
React fait la différence sur la sortie (qui est un format sérialisable connu, les attributs DOM). Cela signifie que les données source peuvent être de n'importe quel format. Il peut s'agir de structures de données immuables et d'états à l'intérieur des fermetures.
Le modèle Angular ne conserve pas la transparence référentielle et est donc intrinsèquement mutable. Vous modifiez le modèle existant pour suivre les modifications. Que se passe-t-il si votre source de données est constituée de données immuables ou d'une nouvelle structure de données (telle qu'une réponse JSON)?
Vérification sale et Object.observe ne fonctionne pas sur l'état de la portée de fermeture.
Ces deux choses sont évidemment très restrictives pour les schémas fonctionnels.
De plus, lorsque la complexité de votre modèle augmente, il devient de plus en plus coûteux de faire un suivi sale. Cependant, si vous ne différez que sur l'arborescence visuelle, comme React, elle ne grossira pas autant car la quantité de données que vous pouvez afficher à l'écran à un moment donné est limitée par les interfaces utilisateur. Le lien ci-dessus de Pete couvre plus d'avantages.
Vous pouvez lire cet article ( La différence entre Virtual DOM et DOM ) pour en savoir plus sur Real DOM et Virtual DOM. J'espère que cela vous aidera!