Quelques réflexions sur le chargement du module javascript technology_javascript skills

Il n'y a pas longtemps, un internaute m'a demandé comment utiliser requireJs et seajs sur le front-end. Je lui ai demandé si votre entreprise disposait auparavant de bibliothèques javascript ou de frameworks javascript auto-écrits. Sa réponse n'était rien, il vient d'en entendre parler. Des choses comme requirejs et seajs sont de nouvelles choses et de nouvelles technologies, et elles sont très précieuses, donc je veux les utiliser.

La question de cet internaute m'a fait réfléchir à la technologie de chargement de modules JavaScript. Dans le dernier article, j'ai donné la structure de base d'une bibliothèque JavaScript que j'ai écrite. En fait, l'une des raisons pour lesquelles j'ai écrit cet article était que je voulais l'utiliser. requirejs. Ou utiliser une technologie comme seajs pour repenser le modèle de base d'écriture de ma bibliothèque JavaScript. Lorsque j'en ai appris davantage sur cette technologie, j'ai trouvé qu'il était incorrect d'utiliser le système de chargement de modules pour résoudre le problème du découplage du code général et du code métier. dans la bibliothèque JavaScript. , la portée du système de chargement de modules est de résoudre le problème de dépendance entre les différentes bibliothèques JavaScript, plutôt que de vous aider à développer une bibliothèque JavaScript.

Alors c'est quoi le système de chargement des modules javascript ?

Le système de modules est principalement conçu pour résoudre le problème des conflits de noms d'objets d'opération dans différentes bibliothèques JavaScript et le problème des dépendances entre différentes bibliothèques JavaScript. Le système de chargement de modules est destiné aux applications frontales Web à grande échelle ou géantes. applications Web frontales.

Généralement, dans une page d'application front-end web géante, les fonctions de la page sont très riches et le métier est très complexe. De plus, avec le temps, les fonctions de la page changent souvent, donc les développeurs front-end. Il faut souvent développer de nouvelles fonctions pour de nouvelles fonctions, mais dans les affaires réelles, les fonctions des différents modules fonctionnels peuvent se pénétrer les unes les autres, dépendre les unes des autres et avoir des relations complexes. Lorsque la page devient complexe, la relation entre les différents modules fonctionnels. Les bibliothèques frontales deviendront difficiles à gérer et à contrôler. C'est à ce moment-là que le système de chargement de modules devient utile.

Pour la plupart des programmeurs, il n'existe pas beaucoup d'opportunités pour entreprendre de manière indépendante une application frontale Web d'une telle envergure. Cependant, il existe de nombreuses autres opportunités pour développer des applications frontales Web de petite et moyenne taille, telles que le Web au niveau de l'entreprise. projets. Il existe très peu de types de bibliothèques JavaScript utilisées et les dépendances de chaque bibliothèque sont faciles à contrôler. Il n'est probablement pas nécessaire d'introduire un système de gestion de modules. Même les pages Web de nombreuses petites et moyennes entreprises Internet ne le sont probablement pas. aussi performant que le front-end des applications Web d'entreprise. Il est complexe, de sorte que la relation entre ses modules ou ses bibliothèques JavaScript est facile à gérer. En fait, ces applications de petite et moyenne taille comme celles ci-dessus sont toutes destinées à des scénarios certains ou spécifiques. Par conséquent, je pense personnellement que face à de tels projets front-end Web, nous pouvons enfin créer nous-mêmes une bibliothèque JavaScript indépendante. les caractéristiques de cette bibliothèque doivent être similaires à celles de jQuery. Les types de bibliothèques sont similaires : une bibliothèque principale plus plusieurs bibliothèques de plug-ins. Le but de la bibliothèque principale est de résoudre le problème de polyvalence. Elle doit être réutilisable et migrée. alors que le but de la bibliothèque de plug-ins est souvent lié au code métier, mais afin de distinguer les problèmes de portée de la bibliothèque principale et de la bibliothèque de plug-ins, j'ai ajouté la fonction d'espace de noms à la bibliothèque.

La technologie de chargement de modules Javascript et la technologie Hadoop présentent certaines similitudes, c'est-à-dire qu'elles sont toutes deux des technologies destinées aux très grands systèmes. Elles ne peuvent jouer leur rôle que sous certaines conditions, ces technologies sont donc lancées par de grandes sociétés Internet, car de grandes sociétés Internet. les entreprises doivent résoudre des problèmes à mesure que leurs applications deviennent plus grandes et plus complexes. Lorsque votre système en est encore à ses balbutiements, vous devez souvent être prudent lorsque vous utilisez ces technologies. Nous devons trouver le moyen le plus simple et le plus efficace de résoudre nos problèmes réels. vous pensez que ce système deviendra de plus en plus grand à l'avenir, alors vous devriez conserver les interfaces pour utiliser ces technologies à l'avenir. Si vous les utilisez trop tôt, il est très probable que lorsque l'échelle du système s'étendra, le coût de la refactorisation du système augmentera. le code sera plus élevé.

Pour le système de chargement de modules, son scénario le plus approprié est de résoudre le problème de découplage entre les modules d'applications frontales Web à grande échelle. Si nous écrivons simplement un nouveau fichier javascript et utilisons immédiatement la technologie de chargement de modules, ce n'est pas un problème. C'est un peu une mauvaise utilisation de la technologie. Eh bien, avant d'utiliser une certaine technologie, nous devons non seulement réfléchir à la manière dont elle est utilisée, mais également à son intérêt.

La dernière chose que je veux dire, c'est que je pense que les applications Web frontales de petite et moyenne taille devraient être déployées en production. Étant donné que JavaScript n'est pas le plus complexe, il est préférable de regrouper tous les fichiers JavaScript externes dans un fichier JavaScript. fichier externe. L'avantage est que cela réduit le nombre de requêtes http, l'utilisation de la technologie de chargement de module rendra difficile, voire impossible, le regroupement de fichiers (les modules comme requirejs et seajs sont basés sur des fichiers, et chaque module est un fichier indépendant. ). Cela revient à résoudre le problème de la réduction de http.