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 profonde 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 niveaux et conceptions granulaires, en séparant conceptuellement le « noyau », les « outils » et les « composants ». Chaque petite fonction est placée dans un fichier. Si nécessaire, vous devez en citer un grand nombre. des démos données dans la documentation yui adoptent 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, il est même nécessaire d'introduire trois ou quatre js. déposer. Il y a deux raisons pour lesquelles yui fait cela. Premièrement, yui est trop gros et il est un peu peu fiable de regrouper toutes les fonctions dans un seul fichier. Deuxièmement, cela ouvre la voie à la conception d'un framework chargé dynamiquement.
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, il n'est pas nécessaire d'initier une requête http. vraie requête http après la mise en cache du fichier chargé dynamiquement. Demande, deuxièmement, le chargement dynamique peut réaliser un chargement à la demande et peut être basé sur des fichiers js. La déduplication et le tri des interdépendances, le chargement de fichiers js avec des balises manuscrites obligent les développeurs à accorder une attention particulière au tri, à la duplication, etc. des fichiers. Troisièmement, le chargement dynamique est propice à la sémantique du code de la page, ce qui fait que les développeurs ne se soucient que de « Quoi ». dont vous avez besoin », plutôt que « 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 sera également un problème lors de la réutilisation du code. De même, lors du débogage, les ingénieurs doivent également ouvrir deux fenêtres pour 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 la structure HTML typique et la logique de démarrage js. S'il souhaite réutiliser, il peut simplement copier l'intégralité du bloc.
<!–Un segment de code HTML logique–>
<script src="logicA.js" />
<script>
$.onDomReady(fonction(){
___LogicA.start();
});
</script>
…
<!–B segment de code HTML logique–>
<script src="logicB.js" />
<script>
$.onDomReady(fonction(){
___LogicB.start();
});
</script>