Break Apart Your Backbone.js Render Methods
ianstormtaylor.com
ianstormtaylor.com
Rivets does look promising in that there are some parts of my code in templates that are just a single number (say # of notifications). That's a pain to have to separate out into a separate view or render function for something so small.
I'm curious, what kind of changes have you adopted to as a result?
Have them do one thing and do it well, keep them unix like, small sharp tools. You can always copy paste a large conditional from one function into its own named function. This significantly improves readability and divides the code in to smaller units which makes testing more graceful.
You can probably argue both ways though, I used to have labels be their own view actually. It just got a bit more uselessly complicated for so little benefit.
If the view you're dealing with is an end node in the view hierarchy (and it's pieces are relatively simple) then I prefer not to split them up because there are costs there as well.
but breaking apart your render method is only one way to achieve this. using a sane layout manager with subviews is my preferred approach (though i suppose you could argue this is just breaking up the render method across several views). this technique is also admittedly a pain at small scales.
the beauty of this technique, though, is that every view is responsible for it's own rendering. that is, parent views don't need to be aware of the re-rendering process of their subviews (how or when). another great benefit is you will find yourself referencing items by selector less often, and instead through the subview's element.
The template for the main view, or the subview that can hold modules,is structured in such a way to have a .container to append my modules into.
The main view is usually rendered only once and behave as a proxy for the various modules relying to the events.
The great benefit form this approach is that it's quite easy to maintain/replace a single module as long as the events api don't change.
second is i actually define the sub views element from the parent view on instantiation, and operate under the assumption that all subviews will render by emptying their element and replacing it's contents. the primary reason is so the root subview element never changes (which can lead to complexity).
About the models I prefer to use an unique one for maintenance and team development cause it's harder to accidentally break things.
It's just a question of how small you really want subviews to get. I personally don't think it's beneficial to have a single label be its own view. Especially when you could have many many inputs on a page.
Is there an easy way to manage this? From what I've seen it's typical to have one template per view (and possibly sub-views with sub-templates).
I used to be very liberal with line breaks, but then seeing methods as their own blocks gets harder. It's just a trade-off. Those example methods could probably use a single line break each, I'll give ya that :p