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.