Maison > Article > interface Web > Comprendre le développement modulaire des compétences Javascript_javascript
Little A est ingénieur front-end au sein d'une équipe de startup et est responsable de l'écriture du programme Javascript du projet.
Conflit de variables globales
Sur la base de sa propre expérience, Xiao A a d'abord extrait certaines fonctions couramment utilisées, les a écrites en tant que fonctions et les a placées dans un fichier public base.js :
Little C est un collègue de Little A. Il a rapporté à Little A : Sa page a introduit une bibliothèque de classes appelée underscore.js, et cette bibliothèque de classes occupera également la variable _ globale, elle suivra donc _ dans la base. js conflits. Little A s'est dit que underscore.js est une bibliothèque tierce et qu'elle est probablement difficile à modifier, mais base.js a été déployé sur de nombreuses pages et il est impossible de le modifier. Au final, Little A n'a eu d'autre choix que de changer les variables globales occupées par underscore.js.
À cette époque, Little A a découvert que placer toutes les fonctions dans un espace de noms peut réduire la probabilité de conflits de variables globales, mais cela ne résout pas le problème des conflits de variables globales.
Dépendance
Avec le développement de l'entreprise, Xiao A a écrit une série de bibliothèques de fonctions et de composants d'interface utilisateur, tels que le composant de commutation d'onglets tabs.js. Ce composant doit appeler des fonctions dans base.js et util.js.
Un jour, les nouveaux collègues Xiao D et Xiao A ont signalé qu'ils avaient référencé tabs.js dans la page, mais que la fonction n'était pas normale. Little A a découvert le problème au premier coup d'œil. Il s'est avéré que Little D ne savait pas que tabs.js dépend de base.js et util.js, et il n'a pas ajouté de références à ces deux fichiers. Alors, il a immédiatement apporté des modifications :
Petit A s'est dit qu'en tant qu'auteur, il connaît naturellement les dépendances des composants, mais c'est difficile pour les autres de le dire, surtout les nouveaux arrivants.
Après un certain temps, Xiao A a ajouté une fonction au composant de changement d'onglet. Afin de réaliser cette fonction, tabs.js doit également appeler la fonction dans ui.js. À ce moment-là, Little A a découvert un problème sérieux. Il devait ajouter des références à ui.js sur toutes les pages qui appelaient tabs.js ! ! !
Après un certain temps, Xiao A a optimisé tabs.js. Ce composant ne dépend plus de util.js, il a donc supprimé les références à util.js dans toutes les pages qui utilisent tabs.js. Sa modification a posé un gros problème. L'équipe de test MM lui a signalé que certaines pages étaient anormales. Little A a jeté un coup d'œil et s'est soudain rendu compte que d'autres fonctions de certaines pages utilisaient des fonctions dans util.js. Il a supprimé la référence à ce fichier et une erreur s'est produite. Pour assurer un fonctionnement normal, il a restauré le code.
Petite réflexion encore, y a-t-il un moyen de modifier les dépendances sans modifier les pages une à une, sans affecter les autres fonctions ?
Modulaire
Lorsque Little A naviguait sur Internet, il a accidentellement découvert une nouvelle méthode de codage modulaire qui pourrait résoudre tous les problèmes qu'il avait rencontrés auparavant.
En programmation modulaire, chaque fichier est un module. Chaque module est créé par une fonction appelée définir. Par exemple, après avoir transformé base.js en module, le code deviendra comme ceci :
Comment appeler l'interface fournie par un certain module ? Prenons tabs.js comme exemple, cela dépend de base.js et util.js :
En raison du manque de support natif du navigateur, si nous voulons coder de manière modulaire, nous devons utiliser quelque chose appelé un chargeur.
Il existe actuellement de nombreuses implémentations de chargeurs, tels que require.js et seajs. La bibliothèque de classes JRaiser possède également son propre chargeur.