2017-05-26 2 views
0

Je voudrais savoir quel est le mécanisme derrière la resversion des dépendances du module circulaire commonjs/requirejs. Laissez-moi vous donner un exemple.CommonJS/RequireJS - Dépendances des modules circulaires

Supposons aussi que nous avons la structure suivante du module

modulea 
    index.js 
    submodulea_a.js 
    submodulea_b.js 

moduleb 
    index.js 
    submoduleb_a.js 
    submoduleb_b.js 

où Modulea/index.js et moduleb/index.js juste réexportations fonctionnalité intéressante de sous-modules. à savoir:

var aa_class = require("./submodulea_a").aaclass; 
var ab_class = require("./submodulea_b").abclass; 

module.exports aa_class; 
module.exports ab_class; 

aussi, laisse supposer que dans aa sous-module je ferai:

var ba_class = require("moduleb").ba_class; 

même est valable pour B, mais permet de dire que, dans le sous-module b: Je ferai

var aa_class = require("modulea").aa_class; 

Comme vous pouvez le voir, il n'y a pas de dépendance circulaire directe d'une classe à l'autre entre modules mais il y a une dépendance circulaire du module car modulea nécessite moduleb et moduleb nécessite modulea (mieux dit, réexporte quelque chose de sous modules).

Comment cela est-il résolu par le nœud commonjs ou requirejs afin d'éviter le débordement de la pile? Y at-il quelque chose comme «liaison tardive» ou quoi que ce soit? Je dirais que non comme commun est synchrone autant que je sache.

Merci

EDIT:

Je l'ai fait des recherches avec la structure du module décrit et il semble qu'il fonctionne de façon similaire le processus suivant:

  1. nom du module Resolve (package.json , node_modules, chemins relatifs ...)
  2. Charger le code du module (fichier .js)
  3. Marquer le module en cours d'initialisation (résolu)
  4. Préparez "empty" ({}) les exportations et publiez-le pour le module en cours (les autres modules l'utiliseront pour les importations pendant require même s'il est vide)
  5. module chargé de processus (exécuter) et si besoin est trouvé, résoudre le module de la même manière que le courant d'une
  6. une fois l'exécution du module est fait, marquer comme il est initialisé (résolu)

si le module en cours d'initialisation ou d'initialisation doit être chargé à nouveau, la version mise en cache de ses exportations est utilisée.

les problèmes qui ne peuvent être résolus:

Lorsque le module circulaire est sur le point d'être chargé, il semble qu'il n'y ait aucun moyen comment résoudre:

var aa_class = require("modulea").aa_class; 

à l'intérieur du module B comme aa_class de le module A n'est pas disponible au moment où il était nécessaire comme initialisation du module A remis l'exécution au module B avant que la classe aa_class ne soit exportée du module A. Donc seule la chose disponible pour le module B est vide exporte l'objet du module UNE.Et je ne vois aucun moyen de résoudre ce qui est mauvais parce que si je voudrais étendre la aa_class dans bb_module je suis perdu.

Répondre

0

Y a-t-il quelque chose comme «liaison tardive» ou quoi que ce soit?

Avec RequireJS oui il y a. Vous pourriez l'appeler «liaison tardive» ou «chargement paresseux».

La documentation sur Circular Dependencies utilise cet exemple.

//Inside b.js: 
define(["require", "a"], 
    function(require, a) { 
     //"a" in this case will be null if "a" also asked for "b", 
     //a circular dependency. 
     return function(title) { 
      return require("a").doSomething(); 
     } 
    } 
); 
+0

Merci pour la réponse. Mais je n'ai pas bien compris la documentation. J'ai fait des tests moi-même car j'étais trop paresseux pour analyser la source. Voir ma modification. – Fis