3 ms·
the problem the author is solving is clear; "Instead of writing gigantic render functions that do everything under the sun (and then more, admit it!) you should
by catshirt 14y ago
the problem the author is solving is clear; "Instead of writing gigantic render functions that do everything under the sun (and then more, admit it!) you should break your render methods into small chunks. That way you only ever re-render what you need."
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.
- federicoweber 14y agoI do structure my code in a similar way. All the elements in a view, that have to deal with data, are treated as a separate view module. Each module will have it's own view, template, model and style. 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.
- catshirt 14y agoawesome, yep. sounds nearly identical to my tactic; with 2 minor exceptions. first being i don't necessarily have a unique model for each view- lots of times my subviews use the same model as the parent or sibling views. 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).
- federicoweber 14y agoSame here for subview rendering. About the models I prefer to use an unique one for maintenance and team development cause it's harder to accidentally break things.
- ianstormtaylor 14y agoCompletely agree. http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt-always-simple/ http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt... 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.