What's the appropriate granularity for Backbon

问题:

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!

回答1:

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 ;)

回答2:

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.