Backbone.js 视图的合适粒度是多少？

Question

我正在采用 Backbone.js 来渲染一个小角落 现有的大型网络应用程序. 。如果进展顺利，我可以看到 Backbone.js 不断发展以涵盖整个应用程序，为有机增长的应用程序提供一些急需的结构。这就是前言。现在针对问题：

我有一个选择框，允许用户选择阅读计划。当选择发生变化时，视图会更新一些描述性文本、日历界面和一个用于将今天的阅读标记为完成的小部件。该小部件将为今天条目中的每个阅读（一个或多个）提供一个复选框，以及一个用于继续第二天阅读的按钮。（您可以在右侧看到该接口当前的非 Backbone 版本（减去完成方案） 现有的应用程序.

每个视图的合适粒度是多少？我已经确定了以下“棘手的部分”：

• 选项卡本身，包含所有包含的控件。
• 选择框
• 描述性文本，响应选择框
• 响应选择框的日历
• 读数小部件响应选择框，包含：
  • （可选）“开始”按钮，用于激活当前计划。
  • 激活后，一个或多个复选框对应于今天条目中的各个读数。
  • 激活后，“下一步”按钮将完成今天的输入并显示下一个。

这些要点中的每一个都应该有自己的视图吗？只是主要部分（选项卡、选择框、小部件）？第一个会产生相当多的视图。第一个似乎可能导致视图实现过于复杂。什么是最好的？

笔记： 我意识到这可以被解释为一个非常主观的问题，但我仍然专注于 Backbone.js 和 Javascript/DOM MVC 模式，并且我希望有一个狭窄的“这是预期的/效果最好的” “来自更有经验的 Backbone.js 从业者。谢谢！

Answer 1

你的问题没有明确的答案。你可以看看 sproutcore 的粒度作为例子。

您还可以观看 http://vimeo.com/17186379 Yehuda Katz 说明了更新页面不同部分的困难。

查看它的一种方法是检查应该使用不同的模型更改/事件刷新哪个部分，并尝试最小化重新渲染。

抱歉，正如您指出的那样，没有好的答案；）

Answer 2

一般来说，视图的粒度取决于在特定 UI 部分的复杂性和视图过度碎片化之间找到平衡。我可能不会将视图用于像按钮这样小的东西（CSS 类就是您真正需要的）。

在您的特定情况下，我可能有一个日历小部件的视图 - 因此可以在应用程序的其他地方轻松地重用它 - 以及整个 Devotions 选项卡的视图。其余的可以通过事件绑定来完成。

关于模型更新和重新渲染，Backbone 的整个想法是将关注点与视图分开。当模型的属性发生变化时，模型会发出“更改”事件，无论当时页面上出现什么视图，并显示该特定模型的数据，都将收到更改通知，并且可以自行更新。