2013-06-19 4 views
1

Je crois que les quatre méthodes ci-dessous fonctionneront, mais je ne comprends pas pourquoi quelqu'un utiliserait les trois premières simplement parce que c'est plus de code. Cependant, le premier (et le plus prolixe) est celui donné dans les documents RequireJS.Gérer les dépendances circulaires

define "circular1", ["example1"], -> "circular1" 
define "circular2", ["example2"], -> "circular2" 
define "circular3", ["example3"], -> "circular3" 
define "circular4", ["example4"], -> "circular4" 

#1 
define "example1", ["require", "circular1"], (require, circular) -> 
    alert "example1 Before: " + circular 
    circular = require "circular1" 
    alert "example1 After: " + circular 

#2 
define "example2", ["require"], (require) -> 
    alert "example2 Before: " + circular 
    circular = require "circular2" 
    alert "example2 After: " + circular 

#3 
define "example3", ["circular3"], (circular) -> 
    alert "example3 Before: " + circular 
    circular = require "circular3" 
    alert "example3 After: " + circular 

#4 
define "example4", [], -> 
    alert "example4 Before: " + circular 
    circular = require "circular4" 
    alert "example4 After: " + circular 

require ["example1"], -> 
require ["example2"], -> 
require ["example3"], -> 
require ["example4"], -> 
  • Si circularDependency va être indéfini jusqu'à ce que vous faites la require explicite, quel est le point de prendre la peine de l'inclure dans la définition (# 1 & # 3)?
  • Et si require est toujours disponible globalement en tant que premier script chargé, pourquoi le transmettre? Est-ce juste une question de clarté du code, à savoir. est-ce juste pour fournir un instantané soigné de toutes les dépendances en haut du code (puisque vous ne pourrez peut-être pas contourner le require explicite plus tard ou a-t-il un impact réel sur la façon dont RequireJS fait l'optimisation selon que ou non il est inclus dans le define?

Je ne veux pas utiliser ces variations si elle a un impact négatif sur mon logiciel juste parce qu'il « fonctionne ».

Répondre

1

Lorsque RequireJS se charge chaque En spécifiant le module dans la liste des dépendances, il est demandé à RequireJS de charger ce module avant de pouvoir appeler la fonction du module. n. Comme require est synchrone et n'essaiera pas de charger un script de manière synchrone, si le script n'a pas été chargé, il ne pourra pas vous renvoyer le module. Puisque require est supposé résoudre les ID de modules relatifs par rapport au module requis, vous devez utiliser le require qu'il vous passe. Donc:

  1. La première façon est correcte. Il indique à RequireJS de charger le module s'il n'a pas déjà été chargé. Si circular est initialement undefined, il peut bientôt le peupler ensuite avec l'autre module.

  2. La seconde méthode est incorrect. Si circular2 n'a pas été chargé, l'appel à require ne fonctionnera pas. Il va résoudre l'ID du module correctement, car il utilise le require il a été donné.

  3. La troisième voie est correcte dans ce cas, mais si vous avez passé un ID de module relatif comme ./circular3, il ne fonctionnerait pas. Il demande aussi à RequireJS de charger le module s'il n'a pas déjà été chargé, donc vous ne rencontrerez pas le problème dans # 2. La seule différence est qu'il utilise le require global, qui n'a pas le contexte du require passé à la fonction d'usine, donc si vous lui passez un ID de module relatif comme ./circular3, il ne sait pas quoi résoudre par rapport à.

  4. Cette manière combine l'inexactitude de # 2 et # 3. Tout d'abord, il ne peut pas résoudre correctement les ID de module relatifs. Deuxièmement, même s'il peut résoudre correctement les ID relatifs, il ne chargera toujours pas les modules s'ils n'ont pas déjà été chargés.

Si vous pouvez garantir que le module circularN sera toujours défini avant un module exampleN exige, alors oui, cela va fonctionner, mais en utilisant des moyens # 1 et # 3 fait que cela fonctionnera même si cela est pas le cas.

+0

Merci. J'ai fini par comprendre à la dure quand j'ai essayé ceci dans jsFiddle qu'être dans le même fichier (c'est-à-dire le contexte) faisait échouer les choses qui auraient dû marcher. La clé, comme vous l'avez dit, est que vous devez charger le module avant de pouvoir l'exiger. Je suis toujours curieux de savoir pourquoi # 3 fonctionne quand les docs disent "soyez sûr de spécifier require comme une dépendance si le bon contexte est utilisé pour chercher un". Cela semblerait impliquer que # 3 pourrait conduire à un contexte incorrect utilisé. – neverfox

+0

@neverfox: Maintenant que j'ai lu cet extrait de documentation, je me rends compte qu'il y a en fait une chose importante que j'ai manquée dans ma réponse. J'ai mis à jour ma réponse pour le couvrir. – icktoofay

+0

Réponse très complète. Merci! – neverfox

Questions connexes