>what were the arguments for/against implementing this functionality from within the templates and not from some place else
It is still quite possible for parent views to construct subviews and insert them into its own DOM at any time, but due to the nature of our views, many of them are UI components, and so it made sense to be able to define both the subview as well as its position at the same time. It makes writing a view with subviews very easy. You simply use the Handlebars helper exactly where you want that view and the rest is taken care of for you.
>You would bind the events on the list (just once, for all items) and find a way to know on which item the event was triggered.
Yes, that's a very common approach to handing DOM events, but it ran against our belief that views should be independent. If a view can only work in a particular situation (eg: nested inside a list which handles its events), then that creates hard dependencies between those two views and you can quickly get into a mess. Event delegation is definitely used in Next, but only at a per-view level. It is a sacrifice (I would posit that it's a minor sacrifice), but the benefits are highly independent and reusable views. We do take advantage of this, too: for example, if you look at the waveform in the player, and the miniature waveform in the header which shows your currently-playing sound (visible in the screenshot), that is the exact same view. Because they handle everything themselves, there was absolute minimum work needed to add that feature.
Thanks for the feedback and the interest,
Nick.
Note that I'm just talking about our particular project: YMMV, and using event delegation in higher level views for your own project might provide bigger wins in terms of performance or maintainability.
> It makes writing a view with subviews very easy. You simply use the Handlebars helper exactly where you want that view and the rest is taken care of for you.
It does indeed look very simple and easy but what I would be concerned about is that you have logic in your views that perhaps shouldn't be there. Your views are now dependent on the template language/parser you are using. Have you tried any other approaches that didn't work so well/easy before coming to this solution?
> If a view can only work in a particular situation (eg: nested inside a list which handles its events), then that creates hard dependencies between those two views and you can quickly get into a mess.
Agree. But how about having per view instance dependency instead of per view constructor. For example,
So your user-badge view can bind its events on the parent_view.el (if available), otherwise on itself. Backbone does this in a way on its delegateEvents method. If there is no selector specified in your event it uses bind on this.$el, otherwise it uses this.$el.delegate.
That's not a bad idea actually -- I might look into that. With only one subview, it ends up with the same amount of handlers, so the benefit would only be seen in list-like views with repeated subviews, right?
>what were the arguments for/against implementing this functionality from within the templates and not from some place else
It is still quite possible for parent views to construct subviews and insert them into its own DOM at any time, but due to the nature of our views, many of them are UI components, and so it made sense to be able to define both the subview as well as its position at the same time. It makes writing a view with subviews very easy. You simply use the Handlebars helper exactly where you want that view and the rest is taken care of for you.
>You would bind the events on the list (just once, for all items) and find a way to know on which item the event was triggered.
Yes, that's a very common approach to handing DOM events, but it ran against our belief that views should be independent. If a view can only work in a particular situation (eg: nested inside a list which handles its events), then that creates hard dependencies between those two views and you can quickly get into a mess. Event delegation is definitely used in Next, but only at a per-view level. It is a sacrifice (I would posit that it's a minor sacrifice), but the benefits are highly independent and reusable views. We do take advantage of this, too: for example, if you look at the waveform in the player, and the miniature waveform in the header which shows your currently-playing sound (visible in the screenshot), that is the exact same view. Because they handle everything themselves, there was absolute minimum work needed to add that feature.
Thanks for the feedback and the interest, Nick.
Note that I'm just talking about our particular project: YMMV, and using event delegation in higher level views for your own project might provide bigger wins in terms of performance or maintainability.