Hello, I’m interested in what is the general opinion of what kind of state to preserve in each of Ember’s layers. For example, what kind of state do you usually keep in Views? in Routes? in Controllers? Models?
Surely, with a complex enough app, at some point in time there would be some kind of state in each. With the question of state comes a question of how to define proper responsibility for each layer, I’m wondering what is the general opinion here too.
Thanks
Don’t have a lot of time, but I wanted to give a quick response:
Application state belongs in controllers. If it’s persisted it should be a model. Routes shouldn’t have state, view state should ideally live in a controller if you want it long-lived, otherwise it’ll get lost upon app navigation.
Thanks @ebryn I’m already familiar with this, as it also stems from official documentation. However, many times I find myself being pushed by Ember to scatter responsibilities all around (e.g. in View, in Controller, and in Model).
To make it a bit more structured, I’m now adhering to the Xeroxish MVC. That is, a rendered View takes action through controller (target=controller) and only through controller (which makes the View virtually empty of actual methods).
The controller will then take action on the Model, which will cause the view to update by virtue of binding (which Ember is awesome at).
This completes a cycle of user input and refresh.
Given, it does make a ton of boilerplate and dull delegation, for example when a controller has nothing to do but just delegate to the model in turn. However from experience soon enough the need will arise and that same dull controller method will fill up with additional concerns that aren’t relevant to the model.
So, for me this is how I wrap my mind around the layers in Ember. This kind of “rigidness” or rules, make a good training wheels as I go along, which makes me wonder about what are others doing.
Thanks
For me the biggest help was using a lot of {{render}} and {{control}}. Especially when the page contains a lot of things, it might be wise to split them app in smaller chunks, so that it’s easier to manage.
This has been the default for a while now 
I think this really depends on the application. If you’re doing a lot of forms, then probably you find yourself with some boilerplate. I’d recommend looking into things like GitHub - DavyJonesLocker/ember-easy-form: Easily build semantic forms in Ember
If this is not the case, please do elaborate
Other than that I think you’re right in what you’re saying, and what @ebryn said. session state should go into controllers, persistent state should go into models. Views should only handle DOM stuff and routes should handle stuff about routing.
Thanks, that sounds reasonably like a good direction.