Ember routing works nicely when working with strict linear paths of resources. However, it’s becoming more prevalent in mobile design for apps — such as the Facebook app — to use infinite stacks of multiple interconnected resources.
Just out of interest, does anyone have an idea of how to achieve what I’ve detailed here in this Stack Overflow post?:
It’s not necessarily super clean and might not be feasible in all scenarios but if you track them via query-params then they should be remember as you move back/forward.
I’m not seeing anything here that Ember’s router does not already support. Can you explain what deficiency you’re seeing that I’m not?
The one that’s probably not immediately known, or documented, is persisting the scroll position which can be implemented via ember-state-services accessed in the route deactivate/activate hook, keying off the current model.
Hi Jason, I wasn’t saying I saw any deficiency in Ember routing - I was finding it hard to see how I should best manage state in the given example. My thoughts centered around persisting each route as the user navigated deeper through the stack by nesting routes. That way, none of the parent routes in the stack would be torn down.
As it is, that’s clearly not the approach to take and the gap in my knowledge is ember-state-services. Thanks for the link!
In particular, this video from Oct '15 was really helpful. It explains how ember-state-services creates ‘buckets’ for different model instances. So as per the Facebook example, when navigating back through the stack, state such as scroll position can easily be recalled for multiple visits to different user profile pages (which reference the same route ‘user/:user_id’).
The only gotcha I can foresee is if the user was to visit the exact same route multiple times in one stack, but that can be managed.
I might be missing something here, but why don’t you use the browser’s native stack (more commonly referred as the “browser history”)?
The browser history would be used to manage URLs in the stack, but restoring the exact state of the page (including scroll position, especially when models may be lazy loaded) requires some additional design. That’s where ember-state-services comes in:
EmberJS contains 2 high-level avenues for storing state: controllers (long-term state) and components (short-term state). Controllers are singletons and any state you set on them will stay there until your application is reloaded or you override the previous value. Components on the other hand are created and destroyed as they enter/leave the DOM and any state that is set on them will be removed/reset each time they are recreated. As you build more complex applications you will find yourself needing a way to have some sort of middle ground solution. Something that has properties of both long-term state and short-term state. This is what ember-state-services sets out to provide.
