Backbone.js UI中管理UI状态/处理选择的方法

Question

我的问题涉及此UI示例。

经与方法来管理各种UI视图分量的“选中”状态的麻烦。例如，我有上面的菜单，用户从中进行各种选择。这些选择应该会引起菜单本身的更新（HL选定的项目），并且会导致结果更新，这将根据所作的选择进行更新。另外，菜单有不同的规则。例如，您一次只能选择一个“列表”，但您可以选择多个“标签”。

的一种方法，我在想是要创建包含UI“选择”的状态的主干模型。例如，我可以有一个模型SearchCriteria来保存这些信息。然后，当用户在UI中做出选择时，我可以更新此模型。我可以让各种视图组件监听此模型中的更改（以及主数据模型中的更改）。然后，视图将通过更新哪些项目显示为选中来更新其视觉状态。

一个项目，我用这种方法挣扎是谁应该负责更新项目的选定状态。例如，标签的名单上，我可能有以下几部分定义...

• 标签（模型来表示一个标签）
• TagCollection（集合代表标签的集合）
• TagMenuView （观点代表了可供选择的标签菜单）
• TagMenuItemView（视图，它表示菜单中的单个项目）

我应该......

• 设置在TagMenuItemView用于点击事件侦听器，然后尝试处理1）更新所述SearchCriteria模型，和2）更新菜单，例如视觉状态选择的项目？
• 或者，我应该有更高层次的视图（TagMenuView）监听事件，如用户选择一个标签，并执行那里工作？
• 此外，本示例中的标签菜单允许选择多个项目，但列表菜单一次仅允许选择一个列表。这个“用户界面”规则（或者这是否与搜索有关的业务规则？）会在哪里执行？例如，如果我在每个单独的列表菜单项上监听点击事件，我当然可以更新该项目的视觉状态，但是，我还需要确保更高级菜单视图取消选择其他所选列表。那么，管理视图中待办事项列表菜单（代表整个菜单（ToDoListMenuView）而不是每个单独的菜单项视图）中的“UI”状态会更好吗？

对不起，这么多的问题。我只是很难转向这种发展模式。

Answer 1

你几乎类似于一个我会用一个答案。

如果你认识到list，search，due和tags是搜索过滤器上的待办事项大集合，你的启蒙方式90％。实际上，除了search之外，所有这些都只是“各种标签”！ （除非您有10,000件待办事项，否则没有任何性能或与内存相关的理由来列出待办事项清单;“工作”，“项目＃1”和“个人”仅仅是您专用的标签从您的视图中过滤项目，仅显示与您生活中的某个领域相关的项目。）

创建SearchCriteria模型。 （您不是在技术上搜索，而是在过滤：您从视图中排除那些与您的搜索条件不匹配的内容）。此模型将包含有关您的客户端状态的很多属性。您的搜索条件几乎完全由客户端中的数据驱动（因为搜索一次只适用于一个ToDoList），所以它完全是SearchCriteria相关的，而不是ToDo对象相关的。

所有视图绑定到更改/添加/删除SearchCriteria上的事件。当用户点击任何视图（列表，视图，标签）时，该消息将被转发给SearchCriteria。它会进行适当的内部更改，从而触发视图重新呈现自己。主要的ToDoListView中的一个事件接收者，它在呈现过程中检查搜索条件。喜欢的东西：

ToDoListView = Backbone.View.extend({ 
... 
render: function() { 
    var self = this, 
    toDraw = this.collection.filter(
     function(c) { return this.searchCriteria.passes(c); }); 
    $(this.el).html(''); 
    _.each(toDraw, function(c) { 
     (new ToDoItemView({model: c, parent: self})).render(); }); 
} 

这可能是一个小的个人习惯，传递父对象，并让该项目将自身插入到父的DOM对象。您可以传入任何内容：要附加到的元素。或者，渲染可以返回一个DOM对象，ListView可以进行追加。这是一个品味问题。我已经完成了两个。

你不得不在骨干的父库中挖一点，下划线，以挖掘​​使用的基本精彩。

另外，我经常在一个自动执行的匿名函数中包含一个完整的Backbone应用程序，并且将“searchCriteria”作为变量可以在SEAF范围内访问所有对象，所以它不会是this.searchCriteria，但只是searchCriteria。

您也可以编写SearchCriteria，以便它调用sync，将事件状态写入服务器，然后将其保存为原始JSON对象;同步的好处在于，如果您发送的内容和接收的内容相同，则不会触发事件，因此您不会获得双重渲染效果，使用JSON的好处在于它适合客户端，但不包含服务器的待办事宜关系。

此外，您可以指定特定的客户端行为规则。例如：当您更改待办事项清单时，您可以应用文本搜索条件，或者作为替代方案，您可以决定更改清单将清除文本搜索条件字段;这样做会触发一个会导致“TextSearchView”清除其输入框的事件（您将不得不编写该事件处理程序，但它会是显然您打算这么做）。您可以制定任何您喜欢的规则，例如“更改列表清除所有选项”，但这似乎不明智。我可以很容易想象在我的个人生活中，试图解决我的“项目”列表中的错误和。但如果你明白我的意思，清理搜索框似乎更加合理。