Bilan js 2018 : les raisons fondamentales de l'existence du framework sont les suivantes

Le principal problème résolu par les frameworks js modernes est de garder l'interface utilisateur et l'état synchronisés. Écrire des interfaces d’interface utilisateur complexes, efficaces et maintenables à l’aide de JavaScript natif est presque impossible. J'ai vu de très nombreuses personnes utiliser aveuglément des frameworks (front-end) tels que React, Angular ou Vue, etc. Ces frameworks fournissent beaucoup de choses intéressantes, mais généralement les gens (pensent) utilisent des frameworks parce que :

• Ils prennent en charge la composantisation ;

Ils bénéficient d'un fort soutien de la communauté
Ils disposent de nombreuses bibliothèques tierces (basées sur un framework) pour résoudre le problème ;
Ils ont beaucoup de (bons) composants tiers ;
Ils ont extensions de navigateur pour aider au débogage ;
Ils conviennent aux applications d'une seule page ;

• Mais ce ne sont
pas les raisons fondamentales d'utiliser des frameworks.

La raison la plus essentielle est :

(Il est très difficile de synchroniser l'interface utilisateur et le statut)

Oui, c'est C'est les raisons, voyons pourquoi

Supposons que vous conceviez une application Web dans laquelle les utilisateurs peuvent inviter d'autres personnes (à assister à un événement) en envoyant un e-mail de groupe. Le concepteur UX/UI l'a conçu comme suit : (avant que l'utilisateur ne remplisse une adresse e-mail), il y a un état vide et ajoute des informations d'aide à cet effet (après que l'utilisateur a rempli l'adresse e-mail), l'adresse e-mail est affichée ; sur le côté droit de chaque adresse se trouve un bouton permettant de supprimer l'adresse correspondante.

Le statut de ce formulaire peut être conçu comme un tableau, qui contient plusieurs objets. L'objet est constitué d'une adresse e-mail et d'un identifiant unique. Au début, le tableau est vide. Après que (l'utilisateur) ait entré son adresse e-mail et appuyé sur Entrée, ajoutez un élément au tableau et

mettez à jour l'interface utilisateur. Lorsque l'utilisateur clique sur le bouton Supprimer, supprimez l'adresse e-mail (correspondant au tableau) et

mettez à jour l'interface utilisateur

. Le ressentez-vous ? Chaque fois que vous changez d'état, vous devez mettre à jour l'interface utilisateur. (Vous pourriez dire :) Et alors ? Eh bien, voyons comment l'implémenter sans framework : Implémentation d'une interface utilisateur relativement complexe en utilisant du JS natif

Le code suivant illustre bien l'implémentation en utilisant du JavaScript natif. La quantité de travail requise pour une interface utilisateur relativement complexe est similaire à la quantité de travail requise pour utiliser une bibliothèque

classique

comme jQuery.

Dans cet exemple, HTML est responsable de la création de la page statique et JavaScript modifie dynamiquement (la structure DOM) via <span class="pln" style="color:rgb(72,72,76);">document</span><span class="pun" style="color:rgb(147,161,161);">.</span><span class="pln" style="color:rgb(72,72,76);">createElement</span> . Cela conduit au premier problème : le code JavaScript lié à la création de l'interface utilisateur n'est pas intuitif et facile à lire. Nous divisons la création de l'interface utilisateur en deux parties (Note du traducteur : il doit faire référence aux parties HTML et JavaScript). Bien que nous utilisions <span class="pln" style="color:rgb(72,72,76);">innerHTML</span>, la lisibilité est améliorée, mais les performances (de la page) sont réduites et des vulnérabilités CSRF peuvent exister. Nous pouvons également utiliser un moteur de modèles, mais si nous modifions le DOM sur une grande zone, nous serons confrontés à deux problèmes : une faible efficacité et la nécessité de relier à nouveau le gestionnaire d'événements.

Mais ce n'est pas le plus gros problème (sans utiliser de framework). Le plus gros problème est de devoir mettre à jour (manuellement) l'interface utilisateur à chaque fois que l'état change. Cela nécessite beaucoup de code pour modifier l'interface utilisateur à chaque fois que le statut est mis à jour. Lors de l’ajout d’une adresse e-mail, il suffit de deux lignes de code pour mettre à jour le statut, mais de treize lignes de code pour mettre à jour l’interface utilisateur. (Dans ce cas) Nous avons rendu l'interface utilisateur (interface et logique) aussi simple que possible ! !

Le code est difficile à écrire et difficile à comprendre, et encore plus gênant est que il est très fragile. Supposons que nous ayons besoin (ajouter) de la fonction de synchronisation des données du serveur avec une liste d'adresses e-mail et que nous devions comparer la différence entre les résultats renvoyés par le serveur et les données du tableau. Cela implique de comparer l'identité et le contenu de toutes les données, ce qui peut nécessiter de conserver en mémoire une copie des données avec la même identité mais un contenu différent (lorsqu'elles sont modifiées par l'utilisateur).

Afin de modifier le DOM efficacement, nous devons écrire beaucoup de code point à point (Note du traducteur : fait référence à l'état à l'interface utilisateur). Mais dès que vous faites une petite erreur, l'interface utilisateur et l'état ne seront plus synchronisés  : (éventuellement) des informations manquantes ou erronées, ne répondant plus aux opérations de l'utilisateur, ou pire, déclenchant la mauvaise action prises (comme cliquer sur le bouton Supprimer puis supprimer un élément non correspondant).

Donc, garder l'interface utilisateur synchronisée avec l'état nécessite d'écrire beaucoup de code fastidieux et très fragile.

L'interface utilisateur réactive enregistre tout

Donc, (la raison de l'utilisation du framework est) pas à cause de la communauté, pas à cause des outils, pas parce que de l'écologie, pas à cause des bibliothèques tierces...

Jusqu'à présent, la plus grande amélioration du framework est qu'il fournit (pour nous) une garantie fiable de synchronisation entre les état de l'application et de l'interface utilisateur.

Tant que vous connaissez certaines règles (spécifiques) d'un cadre spécifique (comme l'état immuable), ça devrait aller.

Nous n'avons besoin de définir l'interface utilisateur qu'une seule fois et nous n'avons plus besoin d'écrire un code d'interface utilisateur spécifique pour chaque opération. En même temps, chaque même état a la même sortie (Note du traducteur : fait référence à la cohérence de l'interface utilisateur)<.> : Lorsque l'état change, le framework met automatiquement à jour la vue (correspondante).

Comment fonctionne le framework ?

Basé sur deux stratégies de base :

• Restituer l'intégralité du composant, comme React. Lorsque l'état d'un composant change, la (nouvelle) structure DOM est calculée en mémoire et comparée à la structure DOM existante. En fait, c'est très cher. Par conséquent, le DOM réel est mappé au DOM virtuel En comparant la différence entre le DOM virtuel avant et après le changement d'état, les changements sont calculés, puis la structure du DOM réel est modifiée. Ce processus est appelé réconciliation.

• Surveillez les modifications via des observateurs (ajoutés) comme Angular et Vue.js. Les propriétés de l'état de l'application sont surveillées et lorsqu'elles changent, seuls les éléments DOM qui dépendent des propriétés (modifiées) sont restitués.

Qu'en est-il des composants Web ?

Souvent, les gens comparent React, Angular et Vue.js (frameworks tels que React) avec des composants Web. Cela montre clairement que les gens ne comprennent pas le plus grand avantage de ces frameworks : garder l'interface utilisateur et l'état synchronisés. Les composants Web ne fournissent pas ce mécanisme de synchronisation. Il

seulement fournit une balise de modèle, mais il ne fournit aucun mécanisme de coordination (entre l'état et l'interface utilisateur). Si vous souhaitez garder l'interface utilisateur synchronisée avec l'état interne lors de l'utilisation de composants Web dans votre application, vous devez le faire manuellement (développeur) ou utiliser quelque chose comme Stencil.js ( en interne le même que React , en utilisant des bibliothèques comme Virtual DOM).

Soyons clairs : l'énorme potentiel du framework ne se reflète pas dans la composition des composants, mais dans le maintien de la synchronisation de l'interface utilisateur et de l'état. Les composants Web ne fournissent pas de fonctionnalités associées, vous devez résoudre le problème (de synchronisation) manuellement ou utiliser une bibliothèque tierce. Il est fondamentalement impossible d'écrire des interfaces utilisateur complexes, efficaces et faciles à maintenir à l'aide de JavaScript natif.

C'est la raison fondamentale pour laquelle vous devez utiliser un framework JavaScript moderne.

Faites-le vous-même et ayez suffisamment de nourriture et de vêtements

Si vous souhaitez comprendre les principes sous-jacents et souhaitez connaître la mise en œuvre spécifique du DOM virtuel. Alors pourquoi ne pas essayer de réécrire l’interface utilisateur native en utilisant uniquement le DOM virtuel sans utiliser de framework ?

Voici le

noyau du framework, la classe de base pour tous les composants.

Voici le composant AddressList réécrit (utilisant Babel pour prendre en charge la conversion JSX).

L'interface utilisateur est désormais déclarative et nous n'utilisons aucun framework. Nous pouvons ajouter une nouvelle logique pour changer l'état à volonté sans écrire de code supplémentaire pour maintenir l'interface utilisateur synchronisée. Problème résolu !

Maintenant, à l'exception de la gestion des événements, cela ressemble à une application React, non ? Nous avons <span class="pln" style="color:rgb(72,72,76);">haverender</span><span class="pun" style="color:rgb(147,161,161);">()</span>, <span class="pln" style="color:rgb(72,72,76);">componentDidMount</span><span class="pun" style="color:rgb(147,161,161);">()</span>, <span class="pln" style="color:rgb(72,72,76);">setState</span><span class="pun" style="color:rgb(147,161,161);">()</span> et ainsi de suite. Une fois que vous avez résolu le problème de la synchronisation de l’interface utilisateur et de l’état de l’application, tout s’additionnera naturellement (composants du formulaire).

Le code source complet peut être trouvé dans ce référentiel Github.

Conclusion

• Le principal problème résolu par les frameworks js modernes est de maintenir l'interface utilisateur synchronisée avec l'état.

• Écrire des interfaces d'interface utilisateur complexes, efficaces et maintenables à l'aide de JavaScript natif est presque impossible.

• Les composants Web n'apportent pas de solution aux problèmes de synchronisation.

• Il n'est pas difficile d'utiliser les bibliothèques DOM virtuelles existantes pour créer votre propre framework. Mais ce n’est pas recommandé !

Recommandations associées :

Les raisons et les solutions à l'échec du chargement des fichiers css et js dans le framework php ci

Vidéo : 27 didacticiels vidéo pratiques classiques pour le développement JS front-end

Vidéo : Tutoriel vidéo de conception de framework avancé JavaScript - didacticiel vidéo en ligne gratuit

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!