jashkenas/backbone — pull request #3088 by tomhicks (2014-03-23 13:17:04+00:00)
Title: Allow user defined view options to be assigned onto the view

I'm aware that this has been proposed numerous times, but I've got a slightly different reasoning for this from what I've read in the other pull requests/issues threads. I'm interested in people's thoughts more than I am about getting this merged.

(this ended longer than expected, so the TL;DR is: I want to promote the use of domain-specific language in applications, and relying on ```model``` and ```collection``` 'keywords' makes that hard)

Firstly, since the ```view.options``` property was removed (which is a very good move, IMO) a little bit of convenience has been lost, but removal of an anti-pattern has been gained. This pull request gets that convenience back. Yes, you can write the one-liner in your initiliaze/constructor method, but then you have to know which one to do it in, and what the differences between the two are.

My main reason for proposing this is that using the generic terms 'model' and 'collection' across all views is bad practise, in my opinion. Once you get to an application with a certain level of complexity, the model and collection properties become meaningless and unclear. You're much better off using more semantic terms, such as ```view.person``` for a PersonView.

I would have suggested that the current set of ```viewOptions``` should be reduced to only those that are actually required in order for Backbone to work, and not just to provide convenience. This would have involved removing the ```model``` and ```collection``` properties from that list (and probably some others) but that would of course cause lots of problems for Backbone's dependents.

So it seems like Backbone is attempting to not only provide some convenience, but also to help people write better, more semantic code along the way. With that in mind, I think that encouraging people to move away from using ```.model``` and ```.collection``` all over the place, and making that as easy as possible is desirable. I've seen a lot of misunderstanding of the M part of MV* over the last few years, mainly around thinking that a model is some specialised entity, rather than just 'whatever stuff you are trying to represent'. The other big one is about multiple models for a view, as if somehow that isn't allowed, and you must combine multiple models into a single object containing those objects. I think that elevating ```model``` and ```collection``` almost to the status of keywords in Backbone promotes this kind of thinking.

---

Just a bit of background. I'm currently working in a distributed team with I think more than 25 developers across three continents writing a very large Backbone application. Clarity of intent across the codebase has been harmed by overuse of generic terms (yes this is our fault, not Backbone's, but I figured it could have been prevented if Backbone's generic terms were more easily avoided)