Ce post a été modifié pour la dernière fois par Summer le 13-02-2019 à 14:04
En 2009, le programmeur américain Ryan Dahl a créé node.js projet pour utiliser le langage JavaScript afin de programmer côté serveur.
Cela marque la naissance de la « programmation modulaire Javascript ». La complexité du front-end est limitée, et il est acceptable de ne pas avoir de modules, mais côté serveur, il doit y avoir des modules pour interagir avec le système d’exploitation et d’autres applications, sinon il ne peut pas être programmé du tout.
L’une des idées les plus importantes en programmation de nœuds est celle des modules, et c’est cette idée qui rend possible l’ingénierie à grande échelle de JavaScript. La programmation modulaire était populaire dans le monde JS, et elle était basée sur cela, puis du côté navigateur, des kits à outils tels que requirejs et seajs sont également apparus, pour ainsi dire, sous la spécification correspondante, exigeant toute programmation modulaire avant ES6, même aujourd’hui, avant que le module ES6 ne soit pleinement implémenté.
Dans CommonJS, le module exposition utilise module.exports et exports, et beaucoup de gens ne comprennent pas pourquoi il y a deux objets exposés, qui seront introduits plus tard
Dans CommonJS, il existe une méthode globale require() utilisée pour charger les modules. En supposant qu’il existe un module mathématique math.js, il peut être chargé de cette façon.
Vous pouvez alors appeler les méthodes fournies par le module :
C’est précisément à cause de la méthode require utilisée par CommonJS que la méthode requise employée par AMD et CMD a également été employée plus tard pour désigner le style des modules
Spécification AMD
Avec les modules côté serveur, il est naturel que tout le monde veuille des modules côté client. Et il est préférable que les deux soient compatibles, et qu’un module puisse fonctionner à la fois sur le serveur et le navigateur sans modification.
Cependant, il existe une limitation majeure qui rend la spécification CommonJS inapplicable aux environnements de navigateur. Toujours le code de la section précédente, s’il s’exécute dans un navigateur, il y aura un gros problème
La deuxième ligne math.add(2, 3) s’exécute après la première ligne require('math'), donc elle doit attendre que math.js chargement se termine. C’est-à-dire que si le temps de chargement est long, toute l’application s’arrête là et attend.
Ce n’est pas un problème côté serveur, car tous les modules sont stockés sur le disque dur local et peuvent être chargés de manière synchrone, et le temps d’attente correspond au temps de lecture du disque dur. Cependant, pour les navigateurs, c’est un gros problème, car les modules sont placés côté serveur, et le temps d’attente dépend de la vitesse Internet, ce qui peut être long, et le navigateur est en état de « mort suspendue ».
Par conséquent, les modules côté navigateur ne peuvent pas utiliser « synchrone », mais uniquement « asynchrone ». C’est le contexte de la naissance de la spécification AMD.
AMD est une abréviation de « Définition de module asynchrone », qui signifie « définition de module asynchrone ». Il charge le module de façon asynchrone, et le chargement du module n’affecte pas le fonctionnement de ses instructions suivantes. Toutes les instructions qui dépendent de ce module sont définies dans une fonction de rappel qui ne s’exécutera qu’une fois le chargement terminé.
Les modules doivent être définis avec une fonction défini() spécifique.
•ID : chaîne, nom du module (optionnel)
•dépendances : est le module dépendant que nous voulons charger (optionnel), en utilisant le chemin relatif. , notez qu’il s’agit d’un format de tableau
• usine : méthode d’usine, retourne une fonction module
Si un module ne dépend pas des autres modules, il peut être défini directement dans la fonction define().
Si le module dépend également d’autres modules, alors le premier argument de la fonction define() doit être un tableau qui indique les dépendances du module.
Lorsque la fonction requeri() charge le module ci-dessus, elle chargera Lib.js fichier en premier.
AMD utilise également l’instruction requir() pour charger le module, mais contrairement à CommonJS, elle nécessite deux paramètres :
Le premier paramètre [module] est un tableau, et ses éléments sont les modules à charger ; Le second paramètre est la fonction de rappel après le succès du chargement. Si vous réécrivez le code précédent sous forme AMD, cela ressemble à ceci :
math.add() n’est pas synchronisé avec le chargement du module mathématique, et le navigateur ne suspend pas l’animation. Évidemment, AMD est donc plus adapté à l’environnement navigateur.
Actuellement, il existe deux principales bibliothèques Javascript qui implémentent la spécification AMD :require.js et curl.js.
|
Publié sur 13/02/2019 14:01:09
|
|
|
