backbone.js - Backbone.js-嵌套 View 应该维护彼此的引用吗？

Question

如果 Backbone View 在其render()方法内创建新的 View ，这些 View 是否应作为数据成员维护？典型的渲染方法如下:

render: function() {
  var myView = new MyView({ model: values });
  $('div#value', this.el).append(myView.render().el);
}

这种渲染方法的链接意味着嵌套 View 实际上仅是创建的，因此它也可以链接任何渲染方法并返回构造良好的元素。我认为该 View 用于垃圾收集吗？

如果要修改嵌套的View……也许是繁重的工作，应该只是(重新)创建它，还是应该通过数据成员引用对其进行修改？

我遇到的问题是嵌套 View 接收事件，这些事件要求它们修改自己的嵌套 View ，有时还要修改其父 View 。

我真的不希望top开始到处都吸引听众。由于父级创建一个新的子级View，而原始的子级View保留了对其父级的引用，因此从子级View传递对父级View的引用并从子级View调用render()会导致内存泄漏。

目前，它还不太像框架。是否有人有任何资源可以帮助我以类似框架的方式解决此问题？

Answer 1

(警告:我的回答成了tl; dr专着)

早些时候我也遇到了同样的问题，并且为了完成一些非常复杂的应用程序而做了作业，所以我将提供自己的观点。

学习 Backbone 的最大挑战是，它是如此简单，可以以多种不同方式使用(并且被使用)，以至于很难弄清楚如何做“正确的”事情，或者至少在刚开始时以一种好的方式出来。不仅有使用 Backbone 的真正方法，而且它的灵活性使它成为几乎所有应用程序的绝佳结构，希望我能提供一些指导。 (我可以在此处的每个句子后面加上“IMO”)。

首先，我对主干 View 的了解

在 Backbone 应用程序中，有许多有用的 View 使用方法。我通常在我的应用程序中看到一些重叠的 View 类型:

我通常有一个或多个“根级别” View 。根级 View 通常是初始化，呈现和保留对处理页面特定部分的 subview 的引用的地方。根级别 View 的el通常是“body”或body中的另一个高级元素。在某些情况下，根级 View 具有自己的HTML以进行观察和/或渲染。在其他 View 中，根级别 View 可能根本没有el，而仅管理 subview 。我在全局“应用程序” namespace 对象中保留对每个根级 View (通常只有一个)的引用。

除了“根级别” View 之外，通常还有“ subview ”。 subview 由“父” View 初始化和呈现，该“父” View 可以是根级 View 或另一个 subview 。父 View 负责根据应用程序的要求初始化，渲染，隐藏，显示和/或销毁他们的 child 。有时，父 View 可能会跟踪 subview 的可变数量的实例(例如，一个PlaylistView具有N个SongView)。 parent 经常会提及 child ，但有时是不必要的(下文有更多介绍)。

除了“根级/父级/子级”范式之外，我还倾向于将 View 归为以下两种类别之一:(1)静态的:意味着一旦 View 初始化，即使 View 及其el仍然存在，即使里面的东西变了； (2)基于各种事件的动态变化。通常，我的根级别 View 始终是静态的。它们通常还对应于现有的DOM元素，例如“body”或“＃my-div”。 subview 通常是动态的，但也可以是静态的。 (提示:声明静态 View 时，请使用el: '#element-id'将现有的DOM元素用作el。动态 View 通常不指定现有的el；它们使用tagName id和className来描述动态 View 将生成的元素。)

View 本质上具有3个功能:(1)在其 parent 或响应事件的情况下渲染自己和他们的 child (或在根级 View 的情况下，由路由器或“main”函数初始化时)等)，(2)通过更新模型或集合或触发自定义Backbone事件来响应来自其el(但不包含任何 subview 的el)内的DOM元素的UI事件，以及(3)观察并响应Backbone( model，collection等事件，需要在其el内(但不在任何 subview 的el内)进行渲染或更改。)有时有用的技巧是， subview 可以触发其父对象自身的事件(this.trigger('customEvent')) View 可以观察(childView.on('customEvent', this.handler, this))。

有关 Backbone View 模式的其他有趣观点，请参见:this和this。

现在在这种情况下，关于问题

1)对垃圾收集，范围和内存泄漏的恐惧

如果您在父级的render(或其他)方法中将 subview 实例化为本地var并进行渲染，然后该函数超出范围，那么我可以理解您对垃圾回收的担心，或者该 View 将无法做它需要做的事。无需担心垃圾收集器，只需担心僵尸。如果您的 View 具有任何事件处理程序，无论是在“事件”声明中声明的UI事件处理程序，还是与其他Backbone对象的事件的绑定(bind)，还是与其他基于DOM的事件侦听器的绑定(bind)，即使您不这样做，也不会垃圾收集您的 View 不再引用它-它仍将存在于内存中并响应事件。另一方面，如果 View 没有任何事件处理程序，那么它的唯一工作就是呈现一个元素，因此谁在乎呈现它的javascript对象是否会粘在那儿-它可能会被垃圾回收，因为它应该。请参阅this，以全面了解js垃圾回收及其与Backbone.js的关系。

更大的关注是Zombie views。如果要从DOM中删除 View ，并且实际上在应用程序中的某个时候将其丢弃，则确保它们完全删除了自己，或者确保父 View 应保留对它们的引用并删除它们。并且不要重新创建和替换已创建但未正确删除的 View 。删除是通过在 View 上调用.remove()，再取消绑定(bind)以前使用on(...)使用off(...)绑定(bind)的任何外部Backbone事件来完成的。通过将"listenTo" and "stopListening" methods添加到View原型(prototype)，Backbone的最新版本(1.0+)使此问题更容易解决。如果要在DOM中动态添加 View 或从DOM中动态添加 View ，请理解并使用这些方法来代替开/关。提示:设置a hacky jquery "remove" event like this one可以很容易地使 View 在从DOM中删除其el时自动删除并自行清理 View (如果您的应用程序流中没有可以起到相同作用的事件)。

2)是否应将 subview 保留为父 View 的数据成员？

这取决于。我认为父级 View 出于有限目的而了解子级 View 并不违反MVC的任何黄金原则。有时，如果需要的话，拥有对特定 subview 实例的成员引用的父级是一种管理 subview 的好方法。正如我所指出的，有时父 View 会响应要求它们渲染，重新渲染，隐藏或删除其 subview 的事件。有时，他们可能想听听 child View 触发的事件。但是， parent 不应在 subview el的内部参与过多。

也就是说，不要过度使用这些类型的引用。很多时候，您不需要使用对 subview 的引用，因为 subview 可​​以照顾好自己。正如我提到的， View 一旦呈现，就应该仅A)监视其el内部的UI事件(但通常不监视任何 subview 的el内部)，并响应这些UI事件更新模型或集合或触发事件，或者B)监视来自其他主干对象(通常是模型或集合或其他 View )的事件，并作为响应采取行动(例如，更新其自己的UI元素)。在许多情况下， View 可以照顾自己，甚至可以删除自己。如果另一个View或其他Backbone对象关心您的 View 中发生的UI事件，请更新模型或触发 View 上的事件并让他们观察。同样，如果 View 外部的某些内容需要更新 View 中的呈现，请侦听对模型的更改或等待相应的自定义事件。作为一般原则，除了 parent 在合理的情况下照看自己的 child 之外，观点之间应该幸福地彼此不了解。

3) subview 是否应保留对父 View 的引用？

没有永不。我无法想到一种情况，您需要通过引用父项来完成某件事，而这是通过更改父项所观察的模型或触发事件(例如，自定义事件说 subview 本身或另一个基于“事件”的主干对象上的“嘿，X发生了”。在Backbone中，我使用模型来表示我的数据和状态。因此，如果在 View 中发生更改我的应用程序状态的事件，那么我将更改模型的相应状态属性，并在需要时让其他 View (包括父 View )侦听自动的“change”事件。我还使用了一个类似于总线的全局“vent”对象(只是扩展Backbone.Events的基本javascript对象)来触发和监听应用程序中的事件，有时我会在Views自身上触发事件，以使父对象知道发生了什么事。无论如何工作，都应使您的体系结构尽可能地困惑。

4)我真的不希望top开始到处都吸引听众。

好吧，我猜想关于 Backbone 的一件好事是不必这样做，但是要意识到，观察者模式(即事件和侦听器)和松散耦合是MVC Backbone 风格的核心(请注意，每个Backbone类都扩展了Events) ？)，并且大多数人都相应地使用它。

引用？

我强烈推荐PeepCode tutorials，除非您觉得自己已经处于相当高级的水平。每张12美元，但是您需要从第一个开始，或者从第二个和第三个开始，这并不是很有用。

另外，here's a nice overview。

结束