Is it best practice to have all components/ controllers bubble up state change related events to the router and have the router handle them?
I got to wondering this because of http://emberjs.com/guides/views/ where they say that the delete todo event should goto the router rather being handled in the controller.
This is certainly the current recommendation. I think the naming is a little confusing, I find it clearer to think of the Route as the controller for the current url and the controllers as presenters. As your app grows larger you’ll really appreciate keeping your main actions in the routes as it makes them much easier to find. Otherwise you end up having to hunt through all the components and controllers on the page.
I could be wrong, but I think those docs are out of sync with the future direction of Ember – specifically the mantra of actions up, data down.
I’ve been refactoring an older application to use this new pattern and have been really happy with the results. I definitely feel that server communication should (almost) always occur in the route – it just makes things easier to reason about once your app gets a little bigger.
@opsb @Emerson thanks for your thoughts. I was naturally drifting towards moving more server interaction into my routers but this helps me feel confident in that direction. I kind of wish Introduction - Routing - Ember Guides mentioned it somewhere.
Good point about the documentaron. By the time i heard this was the way to go I already had a huge app which had become painful to follow. It’s one of those issues that you unfortunately only become aware once you’ve already gotten yourself into trouble.
Wow, this is the first I have heard this. Does anyone have any good examples of what this would look like in practice?
@ryanbillingsley I have an update on this. I had the privilege to chat with one of the yapp guys at an ember NYC meetup. He mentioned that they use service to encapsulate their server interactions and they put them in various places not just the router. This has the benefit of keeping your server code grouped in a way thats decoupled from any particular route or component.
I haven’t had enough time to play with this idea yet to appraise if fully but I think if you want a more distributed architecture where components are more intelligent, then you could use services since you can inject a service into a component. But if you prefer a more hierarchical architecture then the router style works quite well. I’ve played with both architectural styles in other languages and both are useful in different situations.
As to implementing the more server stuff in the router, @Emerson and @opsb may have done this in a different way but my version was sending actions up the stack ie component → controller → router and then doing the actual server interaction in the router. Then the data change propagates back via the observed properties.
@varblob interesting. I will have to look more into it. I also came across this after reading your post, How Ember Data affects data down, actions up, which kind of seems like the same as encapsulating any server logic in a service, but only applies if you are using Ember Data of course.
I actually tend to use services as well for encapsulating the server related logic, it’s just that I always put the action handlers in the routes (as opposed to the controllers). As much as possible I now try to stick to actions up /data down (I’ve even got a bunch of custom input helpers that propagate changes straight up to the router rather than mutating a binding).
Really interesting - I wonder how that actually works? I’ve only ever injected session managers into components, and even that felt like I was breaking the rules. Would love to see some code in the wild that uses the services technique.