我发现backbonejs的不同元素的用法非常模糊。从我的未知，这是意图，因为骨干不想成为一个框架，而是更多的一组工具/对象。
我理解backbonejs的大部分内容，但我仍在质疑视图的initialize（）和render（）调用的正确用法。换句话说，应该在每个逻辑中放置什么逻辑。
有人可以解释什么是最佳做法或在视图中正确使用这些来电？
答案 0 :(得分：1)
这是一个非常广泛的问题，但我会试一试。这里的关键点是，对于这些调用，没有“ 正确用法”。 Backbone非常灵活，旨在满足您的需求。这就是为什么它仍然在一个更复杂，但“自以为是”的框架（它告诉你它是“我的方式或高速公路”）的世界中占有一席之地。
Backbone在渲染方面不使用任何魔法。 render()方法是无操作方法，甚至不会自动为您调用。它的存在只不过是暗示通常如何做事。
但是，在实例化视图时会自动调用initialize()方法。 Backbone保证在那时，视图的顶级DOM元素（el）已经创建并准备好附加到它的东西。
但同样，这是非常小的：顶级元素在那里，但尚未附加到DOM（除非您将options.el传递给构造函数，将el设置为现有元素。将el插入DOM也是你的工作。
所以你可以自由决定如何连线。我通常做的是：
我的大多数视图都有一个模板，该模板通常分配给视图的template属性。 （再次，只是一个约定，没有涉及的魔法。你可以命名为foo。）该模板是在initialize()中编译的。
在initialize()中，我建立了与视图应该代表的模型或集合的关系。即，视图观察模型/集合事件，并在数据发生变化时调用render。 （您不必使用Backbone实体作为数据源，当然......可以是任何东西）。
在render()中，数据被输入模板，结果成为el的innerHTML。之后，我确保将el插入到DOM中（如果尚未插入）。
当数据准备就绪时，应首先调用render()。正确的时刻取决于应用程序。可能render()是initialize()中的最后一次通话，或者某些事件会在以后启动。
如果很多听起来像是重复的样板，是的，那就是它的本质。像Marionette这样的框架存在于Backbone之上以处理这个问题。
但是对于那个框架魔术有一个显着的性能损失。因此，当我必须生成大量视图时，我会坚持使用通用的Backbone内容（并使用我的own components之一来加速模板处理。）