Hacker News new | ask | show | jobs
by federicoweber 5036 days ago
I 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.

1 comments

awesome, 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).

Same 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.