CODEWITHSUNDEEP
backbone.js
Poelinca Dorin
Poelinca Dorin

Reputation: 9715

Backbone.js app design principles: extending views vs initializing child views

Long story short, let's say one app has multiple pages with:

My question is, witch is the preferred Backbone way of handling this and why (please argument) ?

  1. Define, a pagination view, a pagination collection, a search model, search view, etc, and initialize each one as a child view in all the necessary pages. This means we will have to append child view elements into the 'master' element, and handle all the communication between these in all necessary pages.

  2. Define a pagination view (with it's own pagination collection and search model) and extending it across all the necessary pages. This does mean that we will have to make use of template partials (for forms, pagination, etc) and bypasses the need of handling communication between child views while also removes the need of appending/removing child view elements.

  3. Please add your way of handling these cases if not found above, remember to argument.

My personal opinion would be 2. And that is because it removes a lot of hustle with communication between child views and it makes everything much more easier to read just by extending classes, instead of having to 'manually' init child views. It also gives one the option to rewrite behavior per page when needed.

Upvotes: 0

Views: 61

Answers (1)

Avram Tudor
Avram Tudor

Reputation: 1526

I think #2 is a poor choice.

It's a very good idea to keep templates as simple as possible. They are basically just the markup that's generated for some input object. In order to get that object to the template, in MV* frameworks you have Views, that can either pass a model to the template or send some formatted data to the template (I prefer this where possible).

Partials just create markup. You'll still have to handle events, updates to the DOM and rendering inside the view. If you only use one view it will have to handle a lot of things, something associated with poor maintainability and a more bug prone codebase. You'll either have a lot of code in the views, or you'll end up with a lot of mixins or doing a lot of inheritance - and I have no idea which is worse.

Big things are a lot harder to test and to reason about. Avoid doing big things.

I think that another big problem with the template partials approach is the fact that you cannot rely on type information (something like interfaces), on the object that ends up in the template. It's probably easy to make it work when you have a partial or two that you just created, but, in time this information will get lost, leading to a bad development experience.

You'll need to make sure views unrelated to your changes are kept updated with the partial changes you just made for a feature.

Keep in mind that software is never done. Things always change.

Instead of thinking about relationships between models you'll have another complex challenge that you need to handle: the coupling of views through partials.

The alternative is a lot better. Composing specialized views is a good approach because each has it's own internal, smaller state and just it notifies listeners when some action takes place. Nobody cares about what's going on there until something happens and then you just get concrete data.

Going with #1 helps you deal with complexity in your application while allowing you to reuse them in other contexts.

Upvotes: 1

Related Questions