When a user logs out I want all the inactive (hidden) components that might be lingering in the ion-router-outlet to be forcibly destroyed. Is there a way to do that programmatically without forcing a page refresh?
Let’s say that you had route guards on all these pages so that they would only activate if there is an authenticated user. Can you describe how that situation would be insufficient for your needs?
I do in fact have such routing guards in my app. Consider the possibility that two people share the same computer. Two users both separately have the right to access a route (they have joint ownership of the underlying object even). User 1 logs in, goes to that route, does some stuff. User 1 logs out. User 2 logs in, and navigates there way to that same route. User 2’s initial conditions by the state that User 1 left that page in.
I guess intellectually I recognize that one approach to solving this problem is to have any page-level component always re-initialize it’s member variables in ionViewDidEnter or ionViewWIllEnter. But it seemed to me slightly more foolproof to just “clear the cache” on logout instead.
Apologies if you’ve seen this post a thousand times, because I know I’ve probably linked to it that many, but check out this approach for managing user-specific information.
So I’m suggesting totally divorcing component lifecycle from authenticated user lifecycle. Let the framework decide if it wants to improve performance by caching pages and components, but create a rule that
UserService (or whatever you call the provider that fulfills this role in your app) is the single source of truth for:
- is an authenticated user present?
- if so, what information do we have on them (name, id, avatar, whatever)
All other clients that need access to this information (be they route guards or UI components) must subscribe to
Observables exposed by
UserService. They can keep local copies, but those local copies must be updated whenever
UserService emits new values.
To directly answer your original question, I’m not aware of any documented way to “clear the cache”. Even if one did exist, I would consider using it wasteful overkill, because there are likely to be performance benefits of doing the caching, otherwise the framework wouldn’t bother with it. It also continues to reinforce a subtle but (IMHO) misguided forced linkage between UI layer lifecycle and business layer lifecycle. There’s no natural reason that a page needs to be torn down and built up again just because one of its sources of data has announced new information. That’s precisely the sort of task that motivated Angular to build around ReactiveX in the first place. And, finally, yes, you could probably come up with an undocumented kludge that would “work” to evict things from caches, but then you end up constantly looking over your shoulder to see if the framework will change its strategy for managing these things, breaking your internal twiddling and opening up the wound again.
Thanks, I appreciate your thoughtful response.