Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to reuse cached component when routing to it? #1440

Open
liuwei108 opened this issue Jul 19, 2018 · 3 comments
Open

How to reuse cached component when routing to it? #1440

liuwei108 opened this issue Jul 19, 2018 · 3 comments

Comments

@liuwei108
Copy link

This problem is mentioned in #374 but can't find any solution of it.
So the problem is, for example, I have two Component: HomeComponent and AboutComponent
In HomeComponent.html a link [nsRouterLink]="['/about']" can route to AboutComponent.
In AboutComponent.html a link [nsRouterLink]="['/home']" can route back to HomeComponent.

When the app start, home component shows, if I:

  1. click about link to go to About page, HomeComponent instance H1 cached, AboutComponent instance A1 created
    2.1 if I click back button in android or IOS, H1 shows, no new Home instance created
    2.2 if I click home link in about page , however, a new H2 instance created, and old H1 still exist.

My concern about this problem is:

  1. step 2.2 would lead to memory leak!
  2. something it is necessary to provide user a button or link to route to another component, but behavior between user router link/button and device back button are difference: one use old instance and one create new. developer have to pay much works to deal with the problem caused by this difference.

I am not sure if navigate via [nsRouterLink] or router.navigate(['/...']) to an cached component causing an new instance created is a bug,
I think, if there is a way to let [nsRouterLink] or router.navigate(['/...']) to reuse cached component instance, that could workaround the problem. and I just use Page.unloadedEvent and Page.loadedEvent to trigger ngOnDestroy and ngOnInit to keep a singleton instance working.

@NickIliev
Copy link

@liuwei108 The answer to your question about step 2.2. is well explained here (the difference between navigation back and navigation forward even if you are navigating to the very same page in cases like "A page" > "B page" > A page" )

@liuwei108
Copy link
Author

Hello NickIliev,

Thank for reply. I saw the explanation in there.
I understand the navigation back and navigation forward behavior differently.
for "A page" > "B page" > A page"
if B page navigate back to A page, then B page instance destroyed and A instance reused, that is good.
if B page navigate forward to A page, then B page instance cached and a new A instance created.

I understand this behavior is by design and may match many scenario.
I just wonder if {N} further release can provide a config option that allow navigate back and navigate forward behavior is the same and always destroy component when nav out from it. (nav cache stack still there so that back button still works just a new instance need to create each time). I believe there are also some scenario need this, after all, angular did this and don't cache any instances when nav out, it would make {N} more friendly to Angular developer without such surprise.

Currently I can workaround by:
Option 1: use wrapped in a layout instead of , but this makes me can't use transition animation and other features that page-route-outlet provides
Option 2: use Page.loadedEvent, unloadedEvenet to hook ngOnInit and ngOnDestroy to unsubscribe some observable subscriptions. but it is not enough as it looks the component instance still exist so memory leak risk exist. I have also write singleton logic in constructor to make sure only 1 instance per component.

Kindly please let me know if above options are feasible, or if you have better idea.

Thanks

Regards,
David

@phacic
Copy link

phacic commented Nov 14, 2018

@luiwei108 can u provide us sample code of the workaround. Thanks

@vakrilov vakrilov added this to Backlog in Plugins Team Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Plugins Team
  
Inbox
Development

No branches or pull requests

3 participants