Analyse détaillée du développement modulaire JavaScript

Le développement

Modulaire est un concept très important dans le développement de Programmation Le coût de maintenance ultérieur d'un excellent projet modulaire peut être considérablement réduit. Cet article présente principalement les choses sur le développement JavaScript modulaire L'article explique le processus de développement modulaire de manière plus intuitive à travers une courte histoire.

Little A est ingénieur front-end au sein d'une équipe entrepreneuriale et est responsable de l'écriture du programme Javascript du projet.

GlobalVariableConflit

Sur la base de sa propre expérience, Little A a d'abord extrait certaines fonctions couramment utilisées et les a écrites sous la forme La fonction est placée dans un fichier public base.js :

var _ = {
    $: function(id) { return document.getElementById(id); },
    getCookie: function(key) { ... },
    setCookie: function(key, value) { ... }
};

Petit A met ces fonctions dans l'_objet pour éviter les conflits provoqués par trop de variables globales. Il a dit aux autres membres de l'équipe que si quelqu'un souhaitait utiliser ces fonctions, il lui suffisait d'importer base.js.

Petit C est un collègue de Petit A. Il a signalé à Petit A que sa page a introduit une bibliothèque de classes appelée underscore.js, et cette bibliothèque de classes occupera également_this Variables globales, ce sera en conflit avec _ dans base.js. 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épendances

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 changement d'onglet tabs.js. Ce composant doit appeler base.js. et fonctions dans util.js.

Un jour, les nouveaux collègues Xiao D et Xiao A ont rapporté qu'ils avaient cité 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 :

<script src="tabs.js"></script>
<script src="base.js"></script>
<script src="util.js"></script>

Cependant, la fonction était encore anormale. A cette époque, Little A a enseigné à Little D : « On dit que c'est une dépendance, donc la partie dépendante doit être placée avant le. partie de confiance ». Il s'avère que Xiao D a mis base.js et util.js après tabs.js.

Petite pensée en lui-même, comme il est l'auteur, il connaît naturellement les dépendances des composants, mais c'est difficile pour les autres, surtout les nouveaux arrivants.

Après un certain temps, Xiao A a ajouté une fonction au composant de commutation d'onglets. 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é util.js de toutes les pages qui utilisent des guillemets.js pour améliorer les performances. 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, existe-t-il un moyen de modifier les dépendances sans modifier les pages une à une, sans affecter les autres fonctions ?

Modularisation

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 :

define(function(require, exports, module) {
    exports.$ = function(id) { return document.getElementById(id); };
    exports.getCookie = function(key) { ... };
    exports.setCookie = function(key, value) { ... };
});

Les interfaces fournies par base.js sont toutes ajoutées à l'objet exports. Et les exportations sont une variable locale, et le code de l'ensemble du module n'occupe pas la moitié de la variable globale.

Comment appeler l'interface fournie par un module ? Prenons tabs.js comme exemple, cela dépend de base.js et util.js :

define(function(require, exports, module) {
    var _ = require('base.js'), util = require('util.js');
    var p_tabs = _.$('tabs');
    // .... 其他代码
});

Un module peut obtenir les interfaces d'autres modules via la fonction locale require. À l'heure actuelle, les variables _ et util sont toutes deux des variables locales et le nom de la variable est entièrement contrôlé par le développeur. Si vous n'aimez pas _, vous pouvez également utiliser base :

define(function(require, exports, module) {
    var base = require('base.js'), util = require('util.js');
    var p_tabs = base.$('tabs');
    // .... 其他代码
});

Une fois que vous souhaitez supprimer util.js et ajouter ui.js, il vous suffit de modifier tabs.js :

define(function(require, exports, module) {
    var base = require('base.js'), ui = require('ui.js');
    var p_tabs = base.$('tabs');
    // .... 其他代码
});

Loader

En raison du manque de natif du navigateur support, si 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.

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!