用骨干交换意见？

Question

我环顾四周，但还没有找到一个很好的解决方案，下面的问题：

我有一个Backbone视图绑定到页面上的一个el是一个容器元素，我将称之为“侧栏“在传统意义上（为了解释的缘故）。 这个侧边栏元素的内部html需要完全改变，取决于路线。但是，页面上的位置永远不会更改，并且将始终填充此容器。

现在，对于最初的原型，我在这个容器和放置在其中的视图之间有1：1的关系（我只编写了一条路径）。然而，现在，我说过，视图需要根据路线进行更改。

由于这些不同的意见有完全不同的HTML标记，事件响应等...... 我曾经认为我有道理有一个更高层次的观点，在子视图交换。当然，一个解决方案，将工作将处理在同一视图中的所有内容，但必要的逻辑将是繁琐的（和非常该死的笨拙）。

目前，这里有我在想什么（已部分实现）：

• 具有该页面元素的顶级视图。
• 根据路线，交换必要的子视图。
  • 这些子视图使用dust.js呈现，其中页面上该组件的.html模板通过AJAX进行惰性加载，编译和缓存。随后的渲染只是用一个新的上下文调用缓存的“编译”函数。
  • 此外，我将初始化并缓存顶级视图中的每个子视图，这样我只实例化，设置事件处理程序等。

然后，根据路线上，查找相关的子视图查看（缓存），并就地当前视图的换入。

现在，正如我所提到的，我有这个大部分编码和...半工作。然而，我正在努力的是如何使每个子视图独立存在并处理交换，但保持所有事件处理程序和当前状态继续存在，无论组件当前是否显示。

基本上是：

• 如何避免彻底摧毁/重新实例每个他们所需要的时间子视图。也许这个操作并不像我想的那么昂贵，我应该简单地做后者。
• 由于顶层View（“经理”，如果您愿意）绑定到容器$ el，所以如何在子视图中进行交换。

我确定有一个简单，优雅的解决方案。不幸的是，我还没有找到它。

Answer 1

就第1点而言，我不认为每次创建视图都太昂贵。

对于第2点 - 我会推荐使用Backbone.Marionette https://github.com/derickbailey/backbone.marionette。它具有布局的概念，可让您定义应用的不同区域并单独渲染/管理它们。

我会推荐Backbone.Marionette不只是为了第2点，但是它让你管理交互的方式在我看来比标准Backbone好得多。