I have an app that lazy loads all its pages. While trying to understand the application flow, I noticed that each time I enter a page, its constructor gets called. That surprised me because I thought constructors only get called once and then pages are cached. I then found this discussion that essentially says “if you use
setRoot to navigate between pages, each time
setRoot is called, the currently loaded page gets destroyed”. The alternative is to use
nav push and
nav pop. I don’t like the suggested alternative - I don’t want to create a stack of pages when my intent is not to pop back.
I’d like to make sure I get this right:
Based on what I read/understood:
- My app uses
setRootto navigate between pages in a sidebar menu (this is exactly how ionic starter sidemenu does it as well). So I assume each time I change pages, the scenarios is exactly similar to ionic v1’s
- This means I can put in code in the constructor that is guaranteed to be called each time I enter the page and I don’t need to put that code in
- My original design goal, when I assumed pages would be cached (and constructors would only be called once) was that each page would subscribe to a service observable to update its data. Basically, one of my pages is a settings page - if you change data there, all other views must discard any cached data. If pages are being killed and re-loaded each time, i don’t see a point of observables - it only made sense in my case if the constructor data structures were cached from past views.
Can you please comment on my assumptions (and the last point too) - should I still use observables to refresh? If the component is getting instantiated each time it enters, and gets killed each time it exits, the purpose of a long standing observable seems lost (especially since in my case, the data won’t change after the view is loaded - lets assume that is guaranteed)