javascript - JavaScript 和浏览器中如何处理循环引用？

Question

我一直在探索各种 MV* 框架中的模式，今天注意到一个奇怪的模式，这似乎会导致一些问题

模型原型(prototype)。有一个属性 collections: []

集合原型(prototype)。有一个属性models: []

当一个集合获得一个新模型时，它会被推送到collection.models中，但模型本身也会被装饰以了解它所属的集合 - 即集合实例是插入 model.collections。

so model.collections[0] 是一个集合，其中包含 .models[0] ，该模型具有集合属性...等等。

最基本的:

var A = function() {
    this.collections = [];
},
    B = function() {
        this.models = [];
        this.add = function(what) {
            what.collections.push(this);
            this.models.push(what)
        };
    };


var model = new A();
var collection = new B();

collection.add(model);

这是犯罪方的行动:https://github.com/lyonbros/composer.js/blob/master/composer.js#L310-313然后再往下插入模型:https://github.com/lyonbros/composer.js/blob/master/composer.js#L781-784

我想将会有一定程度的惰性评估——直到需要的时候才会使用它们。该代码 - 本身 - 有效。

但我也在通过buster.js编写测试，我注意到所有依赖sinon.spy()的测试都会产生InternalError:太多递归 (FF) 或 RangeError:超出最大调用堆栈大小(Chrome)。捕获的 FF 甚至毫无 react 地崩溃了，这是我以前在 Buster 测试驱动程序中从未遇到过的情况 - 它甚至在我的午休时间使用了 3.5GB 的内存。

经过大量调试后，我取消了引用存储，突然之间，一切又恢复正常了。诚然，删除 spy() 断言也有效，但这不是重点。

所以，问题是 - 拥有这样的代码，它是否可以接受，浏览器将如何解释它，瓶颈是什么，以及如何用指向它们所属集合的指针来装饰模型(可能是集合 Controller )和收集 uids 之类的)。

将失败的buster.js测试的完整要点:https://gist.github.com/2960549

Answer 1

浏览器不在乎。问题是您使用的工具无法通过对象图检查循环引用链。这些都是完全合法的，至少如果您想要它们并期待它们的话，它们就是合法的。

如果您想到一个对象及其属性，以及通过这些属性直接或间接引用的对象，那么该程序集就构成了一个图。如果可以遵循周围的引用文献并最终回到开始的地方，那么这意味着图表有一个循环。该语言允许循环绝对是一件好事。它是否适合给定系统取决于相关代码。

因此，例如，如果图是循环的，则遍历对象图而不检查是否已经访问过对象的递归函数肯定会触发“递归过多”错误。