I can’t speak for what the design intention was, but I don’t believe it was accidental and I might be able to give you some examples of why I think it was a smart decision.
- Until a controller is loaded with new data, what good reason is there
to reset its state? Controllers are all visible to each other (via
the “needs”) property, and it’s valid and common to examine the state
of controllers that may not be a part of the active route.
- If you
have a route that looks like collection/group/item, shouldn’t the
state of collection and group stay consistent even as you navigate to
new items? Doesn’t that imply that the natural state of the
controller is to stay constant until changed?
- It’s not hard to blow
out the singleton instance and get a fresh one. The setupController
hook in the route will give you a new controller, as will
transitioning to a route and passing an explicit model, and you can
tie stuff that absolutely should be refreshed on each model change to
In general, I found a lot of these kinds of architectural things very frustrating when I first started working with Ember. When you start “thinking Ember,” you become very grateful for them. Almost everything I was frustrated I couldn’t do for the first 4 months, I was grateful for during the next 4.