Parlons de notre compréhension des frameworks front-end modernes

Ce chapitre parle de la compréhension des frameworks front-end modernes. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Alors pourquoi les gens doivent-ils choisir différents frameworks maintenant ?

En fait, la raison pour laquelle nous devons choisir un cadre maintenant est essentiellement parce que les besoins auxquels nous sommes confrontés ont changé. Tout le monde doit comprendre que si nous écrivons uniquement une page qui affiche uniquement des informations sans aucune fonction interactive, en fait, même maintenant, nous n'avons pas besoin de choisir un framework. Il suffit d'écrire quelques lignes de CSS et de HTML pour terminer la tâche. . Ainsi, comme les exigences auxquelles nous sommes confrontés sont devenues plus complexes, nos applications doivent souvent effectuer certaines interactions au moment de l'exécution.

Il y a ici trois mots très importants que j'ai marqués en gras, appelés Runtime . Dans le développement front-end moderne, les applications que nous développons nécessitent souvent certaines interactions au moment de l'exécution. Au début, ces interactions n'étaient que de simples interactions telles que des diapositives ou des menus déroulants de changement d'onglet. Il n'y a aucun problème à implémenter ces interactions avec jQuery. . Mais notre objectif pour le front-end moderne est d'utiliser le Web pour les applications natives PK et PK avec Native.

À l'heure actuelle, nous constaterons que l'utilisation de jQuery pour développer des applications rend notre code difficile à maintenir. Alors pourquoi devient-il plus facile à maintenir en utilisant des frameworks modernes tels que Vue, React, etc. ?

La seule différence entre Vue et jQuery est déclarative et impérative.

On peut y réfléchir, quel est le but d'utiliser jQuery pour faire fonctionner le DOM ? Il s'agit de mettre à jour la vue localement, autrement dit de restituer localement.

jQuery est un moyen impératif de faire fonctionner le DOM et une vue de mise à jour partielle impérative, tandis que les frameworks grand public modernes tels que Vue, React, Angular, etc. sont tous déclaratifs et une vue de mise à jour partielle déclarative.

Pourquoi la manipulation déclarative du DOM rend-elle les applications plus faciles à maintenir ?

Pour comprendre ce problème, commençons d’abord par présenter brièvement ce qu’est un impératif et ce qu’est un déclaratif.

Impératif

Impératif, comme jQuery, nous voulons tous faire quelque chose et ensuite le faire. Par exemple, le code suivant :

$('.box')
  .append(&#39;<p>Test</p>&#39;)
  .xxx()
  .yyy()
  .jjj()
  ...

L'impératif est de penser. Quoi que vous vouliez faire, appelez simplement la méthode et faites-le directement. C'est simple, direct et brut.

Imaginez une scène très simple, comme un effet bascule, cliquez sur un bouton pour changer de couleur.

Écrivez-le en style impératif. Nous devons l'écrire comme ceci. Si la couleur actuelle est, laissez-la changer de couleur.

Si vous y réfléchissez bien, cela peut en fait être subdivisé en deux comportements, l'un consiste à juger du statut et l'autre à faire fonctionner le DOM.

Alors, qu’est-ce qui est déclaratif ? ?

Déclaratif

Déclaratif consiste à décrire la relation de mappage entre l'état et la vue, puis à faire fonctionner le DOM via une telle relation de mappage, ou à être plus précis, utilisez une telle relation de mappage pour générer un nœud DOM et l'insérer dans la page. Par exemple, les modèles dans Vue. La fonction du modèle est de décrire la relation de mappage entre l'état et le DOM.

Nous utilisons le modèle dans Vue pour implémenter le même scénario. Après avoir utilisé le modèle pour décrire la relation de mappage, lorsque nous cliquons sur le bouton, il nous suffit de modifier la variable de couleur pour compléter l'exigence.

Vous voyez la différence ?

Réfléchissez bien et utilisez Vue pour atteindre la même exigence. Si vous le décomposez, nous n'avons logiquement qu'un seul comportement et un seul état. Et jQuery a deux comportements, état + opération DOM.

Alors pourquoi l'approche déclarative peut-elle simplifier la complexité de la maintenance du code d'application ?

Parce que cela nous permet de nous concentrer uniquement sur le maintien de l'État. De cette façon, lorsque l'application devient complexe, en fait, notre réflexion et la façon dont nous gérons le code se font uniquement en termes de statut, et nous n'avons plus besoin de nous soucier de toutes les opérations DOM. On peut dire que la complexité du code. l'entretien est considérablement réduit.

Nous n'avons plus besoin de prêter attention à la manière de faire fonctionner le DOM, car le framework le fera automatiquement pour nous, il nous suffit de faire attention au statut.

Mais si l'application est particulièrement complexe, nous constaterons que même si nous nous concentrons uniquement sur la maintenance de l'État, cela reste difficile. Même si nous nous concentrons uniquement sur la maintenance de l'État, cela reste difficile, donc des solutions techniques telles. comme Vuex et Redux ont émergé.

Qu'est-ce que le rendu ?

Après l'introduction précédente, vous constaterez que le problème le plus essentiel à résoudre par les frameworks grand public modernes est toujours le rendu. C'est juste que les solutions entre les différents frameworks sont différentes. rendu ?

Désormais, lors du développement du front-end, nos applications doivent effectuer en permanence diverses interactions pendant leur exécution. Les frameworks grand public modernes nous permettent de nous concentrer sur la maintenance de l'état, ce qui signifie que lorsque l'application est en cours d'exécution, à l'intérieur de l'application. le statut continuera à changer.

Le DOM généré par l'état est inséré dans la page et affiché sur l'interface utilisateur. Ce processus est appelé rendu.

Traitement du rendu par des frameworks front-end modernes

Lorsque l'application est en cours d'exécution, l'état interne continuera de changer à ce moment, la page utilisateur Une certaine zone locale doit être constamment restituée.

Comment restituer ?

La solution la plus simple et la plus grossière, qui est également la manière la plus couramment utilisée lorsque j'écris des fonctions simples dans des projets qui n'utilisent aucun framework, consiste à utiliser l'état pour générer un nouveau DOM, puis à utiliser innerHTML pour remplacer le ancien DOM.

Le petit bloc fonction que j'ai écrit ne pose aucun problème de cette façon, car la fonction implique peu de balises DOM. Lorsque l'état change, presque toutes les balises de mon bloc fonction doivent être modifiées, donc même si j'utilise. innerHTML ne gaspillera pas beaucoup de performances et se situe dans la plage acceptable.

Mais le cadre ne fonctionne pas. Si le cadre est remplacé par innerHTML, il ne sera pas partiellement restitué, mais la page entière sera actualisée dans son ensemble. Alors, comment peut-on le faire. le cadre obtient-il un rendu partiel ?

Pour résoudre ce problème, certaines solutions techniques sont nécessaires. Cela peut être VirtualDOM, mais cela ne doit pas nécessairement être VirtualDOM. Cela peut aussi être le processus de détection sale dans Angular, ou cela peut être à grain fin. la liaison, comme Vue1.0, est implémentée à l'aide d'une liaison à granularité fine.

Qu'est-ce que la reliure à grain fin ?

La liaison à grain fin signifie que lorsqu'un certain état est lié, il est lié à une étiquette spécifique dans la page. Autrement dit, s'il y a dix balises dans le modèle qui utilisent une certaine variable, alors les variables sont liées à 10 balises spécifiques.

Par rapport à React et Angular, la granularité est relativement grossière. Leur détection de changement ne sait en fait pas quelle variable d'état est spécifique, donc une comparaison violente est nécessaire. Ce n'est qu'après la comparaison que vous pourrez savoir quelle partie de la vue. doit être modifié.

La liaison fine de Vue sait en fait quel état a changé au moment où l'état change, et sait également quelles balises spécifiques utilisent cet état, alors les choses changent. Vous pouvez atteindre l'objectif du local. update en mettant directement à jour les balises spécifiques liées à cet état.

Mais cela a en réalité un certain coût, car la granularité est trop fine et il y aura une certaine surcharge de suivi des dépendances. Par conséquent, Vue2.0 a commencé à adopter une solution de compromis, qui consistait à ajuster la liaison à une granularité moyenne.

Un état correspond à un certain composant au lieu d'une étiquette spécifique. Cela a l'avantage de réduire considérablement le nombre de dépendances. Après tout, le nombre de composants est beaucoup plus petit que les étiquettes spécifiques dans le DOM. Mais cela nécessite une opération supplémentaire. Lorsque l'état change, seul le composant est averti. Alors, comment le composant sait-il quelle balise DOM mettre à jour ? ?

La réponse est VirtualDOM.

En d'autres termes, lorsque la granularité est ajustée à moyenne, une opération supplémentaire est nécessaire pour utiliser VirtualDOM à l'intérieur du composant pour effectuer un nouveau rendu.

Vue améliore intelligemment les performances du framework grâce à deux solutions techniques : détection de changement + VirtualDOM.

Ainsi, Vue2.0 a introduit VirtualDOM non pas en raison de la qualité de VirtualDOM, mais parce que VirtualDOM combiné à la détection des modifications peut ajuster la liaison à une granularité moyenne pour résoudre le problème de surcharge du suivi des dépendances.

Concernant la détection des changements, j'ai écrit un article spécial pour présenter comment Vue implémente la détection des changements. Portail.

Ainsi, la méthode de détection des changements a, dans une certaine mesure, déterminé le rendu du framework.

J'ai écrit un PPT sur le principe de mise en œuvre de VirtualDOM Si vous êtes intéressé, vous pouvez jeter un œil au portail.

L'autre est la compilation de modèles. En fait, je n'ai pas beaucoup parlé de la compilation de modèles plus tôt. La fonction du modèle est de décrire la relation de mappage entre l'état et le DOM. La fonction de rendu peut être compilée et exécutée.Cette fonction de rendu peut obtenir le VNode fourni dans VirtualDOM. En fait, si vous avez vu le PPT dans lequel j'ai présenté le principe de VirtualDOM plus tôt, vous saurez que VirtualDOM différencie le nœud est en fait une différence avec le VNode. J'ai écrit un article spécial pour présenter le principe de mise en œuvre de la compilation de modèles, portail.

Résumé

Personnellement, je pense que le front-end actuel est un peu impétueux. Beaucoup de gens recherchent de nouvelles choses et prêtent attention à certaines nouvelles fonctionnalités chaque jour. est publié aujourd'hui, et un nouveau est publié demain. Je suis d'accord avec les frameworks et autres, mais j'espère voir son essence tout en poursuivant de nouvelles choses. Le but ultime de toutes les solutions techniques est de résoudre les problèmes. Il y a d’abord un problème, puis il y a une solution. La solution n’est peut-être pas parfaite, et il peut y avoir de nombreuses solutions. Alors, quels sont les avantages et les inconvénients entre elles ? Quels compromis chacun d’eux a-t-il fait pour résoudre le problème ? Il faut voir à travers les phénomènes pour voir l'essence afin de ne pas se laisser dérouter par la surface.

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!