處理循環依賴關係

Question

我相信以下所有四種方法都可以使用，但我不清楚爲什麼有人會使用前三種方法，僅僅是因爲代碼更多。然而，第一個（也是最詳細的）是在RequireJS文檔中給出的。

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"], -> 

• 如果circularDependency是走，直到你做了明確的require爲undefined，有什麼煩心事，包括它的定義（＃1 &＃3）的點？
• 而且如果require總是作爲第一個加載的腳本全局可用，爲什麼要將它傳入？這只是一個代碼清晰的問題，即。是否僅僅爲代碼頂部的所有依賴關係提供了一個簡潔的快照（因爲你可能實際上並沒有到達明確的require，直到很久以後？或者它是否對RequireJS的優化方式有實際影響取決於是否它是不是包含在define？

我不想使用這些變化，如果對我的軟件產生負面影響，只是因爲它「作品」。

Answer 1

當RequireJS加載每個模塊作爲一個單獨的文件，而不是將它們捆綁在一起，這是有所不同的，在依賴關係列表中指定模塊會告訴RequireJS在調用模塊的函數之前需要加載該模塊ñ。由於require是同步的，因此它不會嘗試同步加載腳本，如果該腳本尚未加載，則無法將模塊返回給您。由於require應該解析相對於需求模塊的相關模塊ID，因此需要使用它傳遞給您的require。所以：

1. 第一種方法是正確的。它告訴RequireJS加載模塊，如果它尚未加載。如果circular最初是undefined，則可以很快用其他模塊填充它。

2. 第二種方式是不正確。如果circular2尚未裝載，則對require的呼叫將不起作用。它將正確解析模塊ID，因爲它使用了它給出的require。

3. 第三種方式是在這種情況下正確，但如果你通過它相對模塊ID喜歡./circular3，它是行不通的。它也告訴RequireJS如果它尚未被加載，則加載模塊，所以你不會在＃2中遇到問題。唯一的區別是它使用全局的require，它缺少傳遞給工廠函數的require的上下文，所以如果您傳遞相關模塊ID（如./circular3），它不知道要解決它的相關問題。

4. 這種方式結合了＃2和＃3的不正確性。首先，它無法正確解析相關模塊ID。其次，即使它可以正確解析相關ID，如果它們尚未被加載，它仍然不會加載模塊。

如果你能保證一個exampleN模塊要求之前，該circularN模塊總是會被定義，那麼，它會工作，但使用方式＃1和＃3確保如果是這樣，它仍然工作不是這樣。