Backbone.js 视图的合适粒度是多少？
我正在采用 Backbone.js 来渲染现有大型 Web 应用程序的一个小角落。如果进展顺利，我可以看到 Backbone.js 不断发展以涵盖整个应用程序，为有机增长的应用程序提供一些急需的结构。这就是前言。现在的问题是：
我有一个选择框，允许用户选择阅读计划。当选择发生变化时，视图会更新一些描述性文本、日历界面和一个用于将今天的阅读标记为完成的小部件。该小部件将为今天条目中的每个阅读（一个或多个）提供一个复选框，以及一个用于继续第二天阅读的按钮。 （您可以在现有应用程序的右侧看到此界面的当前非 Backbone 版本（减去完成方案） 响应
每个视图的适当粒度是什么？我已经确定了以下“繁琐的位”：
- 选项卡本身，其中包含所有包含的控件
- 选择框
- 选择框的描述性文本 响应选择框的
- 日历。到选择框
- 读数小部件，它响应选择框，并包含：
- （可选）“开始”按钮，用于激活当前计划。
- 激活后，会出现一个或多个复选框，对应于今天条目中的各个读数。
- 激活后，“下一步”按钮将完成今天的输入并显示下一个。
这些要点中的每一个都应该有自己的视图吗？只是主要部分（选项卡、选择框、小部件）？第一个会产生相当多的视图。第一个似乎可能导致视图实现过于复杂。什么是最好的？
注意：我意识到这可能被解释为一个非常主观的问题，但我仍然专注于 Backbone.js 和 Javascript/DOM MVC 模式，并且我希望有一个来自更有经验的 Backbone.js 从业者的狭义“这就是目的/效果最好”。谢谢！
I'm adopting Backbone.js to render a small corner of an existing large web app. If this goes well, I can see Backbone.js growing to encompass the whole of the app, lending some much-needed structure to an organically-grown application. That's the preface. Now for the problem:
I have a select box which allows the user to select a reading plan. When the selection changes, the view updates some descriptive text, a calendar interface, and a little widget for marking today's readings as complete. The widget will have a checkbox for each reading (one or more) in today's entry and a button for continuing to the next day's reading. (You can see the current, non-Backbone version of this interface (minus the completion scheme) on the right-hand side of the existing app.
What is the appropriate granularity for each View? I've identified the following "fiddly bits":
- The Tab itself, which encompasses all the contained controls.
- The select box
- The descriptive text, which responds to the select box
- The calendar, which responds to the select box
- The readings widget, which responds to the select box, and contains:
- Optionally, a "Start" button, which activates the current plan.
- When activated, one or more checkboxes corresponding to individual readings within today's entry.
- When activated, a "Next" button which completes today's entry and displays the next.
Should each of these bullet points get its own View? Just the major pieces (tab, select box, widget)? The first will result in quite a few Views. The first seems like it could lead to overcomplicated View implementations. What's best?
Note: I realize this could be interpreted as a wildly-subjective question, but I'm still wrapping my head around Backbone.js and Javascript/DOM MVC patterns, and I'm hoping that there is a narrow "this is what's intended/works best" from more experienced Backbone.js practitioners. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说，视图的粒度取决于在特定 UI 部分的复杂性和视图过度碎片化之间找到平衡。我可能不会将视图用于像按钮这样小的东西（CSS 类就是您真正需要的）。
在您的特定情况下，我可能有一个日历小部件的视图 - 因此可以在应用程序的其他地方轻松地重用它 - 以及整个 Devotions 选项卡的视图。其余的可以通过事件绑定来完成。
关于模型更新和重新渲染，Backbone 的整个想法是将关注点与视图分开。当模型的属性发生变化时，模型会发出“更改”事件，并且当时页面上发生的任何视图并显示该特定模型的数据，都将收到更改通知，并且可以自行更新。
In general, the granularity of your views will depend on finding a balance between the complexity of the particular piece of UI, and over-fragmentation of views into little pieces. I probably would not use a view for something as small as a button (a CSS class is all you really need for that).
In your particular case, I'd probably have a view for the calendar widget -- so it can be easily reused in other places in the app -- and a view for the entire Devotions tab. The rest can be done through event binding.
Regarding model updates and re-rendering, the whole idea with Backbone is to separate that concern from the views. Models emit "change" events when their attributes change, and whatever views happen to be on the page at the time, and are displaying that particular model's data, will be notified of the change, and can update themselves.
你的问题没有明确的答案。你可以看看 sproutcore 的粒度作为例子。
您还可以观看 http://vimeo.com/17186379，其中 Yehuda Katz 说明了更新不同内容的困难页面。
查看它的一种方法是检查应该使用不同的模型更改/事件刷新哪个部分，并尝试最小化重新渲染。
抱歉，正如您指出的那样，没有好的答案；）
There is no definitive answer to your question. You can have a look at the granularity of sproutcore for exemples.
You can also watch http://vimeo.com/17186379 where Yehuda Katz illustrate the difficulties of updating different pieces of the page.
One way of looking at it would be to check which part should be refreshed with different model change/events and try to minimize the re rendering.
Sorry no good answers as you pointed out ;)