Radicalité et compromis dans la conception de YUI3

Je crois que chaque ingénieur front-end a son framework JavaScript préféré, qu'il s'agisse d'émotion ou de conviction. Le framework JavaScript apporte non seulement un développement pratique, mais aussi une pure beauté logique, qu'il s'agisse de la simplicité gracieuse de jquery ou de la magie de Yui. bac à sable, ils nous donnent tous une imagination infinie. Cependant, le framework js est forcément incapable d'atteindre la perfection globale. Par exemple, les concessions de jquery en OO et les sacrifices de yui en termes de performances transmettent tous une sorte de beauté imparfaite et un réalisme idéal aux gens. Aujourd'hui, examinons ces sacrifices et concessions faits par yui3 dans la conception du framework, afin que nous puissions avoir une compréhension plus approfondie de l'image complète de yui3 et maximiser ses avantages.

1. Une étape ou granulation des graines

Le soi-disant amorçage en une étape signifie qu'il vous suffit d'introduire une balise de script d'un fichier de départ sur la page, comme prototype et jquery, et d'introduire simplement un prototype.js ou jquery.js. Ils encapsuleront les opérations DOM et. événements, etc. dans un fichier et essayez de le garder aussi petit que possible. Les avantages de cela sont évidents. L'utilisation du framework est très simple. Cependant, Yui a divisé ces fonctions en conceptions hiérarchiques et granulaires, en séparant conceptuellement le « noyau », les « outils » et les « composants ». Chaque petite fonction est placée dans un fichier et doit être référencée par elle-même en cas de besoin. donné dans la documentation yui, adoptez cette méthode. Cette conception n'est évidemment pas aussi conviviale pour les débutants que jquery, et elle n'est pas assez stupide pour être utilisée. Afin d'implémenter une petite fonction, trois ou quatre fichiers js doivent être introduits. Il y a deux raisons pour lesquelles yui fait cela. Premièrement, yui est trop gros et il est un peu peu fiable de mettre toutes les fonctions dans un seul fichier. Deuxièmement, cela ouvre la voie à la conception de son cadre de chargement dynamique.

2. Introduction manuelle ou chargement dynamique

La méthode traditionnelle d'écriture de js dans la page consiste à écrire directement le fichier js dans la page en tant que chemin de balise de script. Vous pouvez également introduire la page de cette manière en utilisant yui, mais yui recommande d'utiliser le chargeur pour le chargement dynamique. L'origine des scripts chargés dynamiquement est très compliquée.À l'heure actuelle, il y a trois raisons principales. Premièrement, les balises js manuscrites dans la page occuperont de toute façon une requête http. Même si la requête est un 304, le fichier chargé dynamiquement n'a pas besoin. pour lancer une véritable requête http après sa mise en cache. Deuxièmement, le chargement dynamique peut réaliser un chargement à la demande, et peut dédupliquer et trier en fonction des dépendances entre les fichiers js. Le chargement de fichiers js avec des balises manuscrites nécessite que les développeurs y prêtent une attention particulière. le tri, la duplication, etc. des fichiers. Troisièmement, le chargement dynamique est propice à la sémantique du code de la page, qui permet aux développeurs de se soucier uniquement de « ce qui est nécessaire » sans se soucier de « comment l'obtenir ». Lorsque les projets deviendront de plus en plus volumineux et que les coûts de maintenance deviendront de plus en plus élevés, ces techniques de petite et moyenne taille seront d'un grand bénéfice.

3. Entrée unique ou bac à sable pour un démarrage logique

Lorsque nous démarrons une logique js dans une page, nous la mettons généralement dans une méthode comme onDomReady. Et s'il y a plusieurs logiques dans la page ? Par exemple, a implémente la logique A et le code de la page est comme ceci

<script src="logicA.js" />
<script>
$.onDomReady(fonction(){
___LogicA.start();
});
</script>

Ce code est généralement écrit à la fin de la page. Le code HTML accompagnant cette logique est enterré quelque part sur la page. À ce stade, b doit ajouter la logique B à la page. terminer, puis modifiez-le pour qu'il ressemble à ceci :

<script src="logicA.js" />
<script src="logicB.js" />
<script>
$.onDomReady(fonction(){
___LogicA.start();
___LogicB.start();
});
</script>

De même, le code html accompagnant la logique B est également enfoui quelque part sur la page. Il semble que la logique js et le code html qui l'accompagne soient tellement séparés que lorsqu'il s'agit de supprimer la fonction, le html est souvent supprimé mais le js est oublié. , ou supprimer js et oublier de supprimer html entraînera également des problèmes lors de la réutilisation du code. De même, lors du débogage, les ingénieurs doivent ouvrir deux fenêtres et se concentrer respectivement sur js et html, même si les deux morceaux de code sont dans le même fichier. Dans ce cas, il vaut mieux écrire le code comme ceci :

Cette méthode de codage est exactement ce que préconise Yui, c'est ce qu'on appelle le bac à sable. Chaque logique est contenue dans un bac à sable, et chacune fait sa propre chose sans interférer les unes avec les autres. Lorsqu'un tiers parcourt le code, il comprend immédiatement qu'il s'agit d'un bloc fonctionnel indépendant, comprenant une structure HTML typique et une logique de démarrage js. S'il souhaite le réutiliser, il peut simplement copier l'intégralité du bloc.

<!–Un extrait de code HTML logique–>
<script src="logicA.js" />
<script>
$.onDomReady(fonction(){
___LogicA.start();
});
</script>

…

<!–B extrait de code HTML logique–>
<script src="logicB.js" />
<script>
$.onDomReady(fonction(){
___LogicB.start();
});
</script>