Ionic 4 Tab to page then back to Tab did not trigger ionViewWillEnter [Solved]

I have an small application where user can edit their account and after edit user route back to my account page.

Situation:

My account Tab > Edit Account Page > Save and Route Back to My account Tab*

When User redirect to My account page none of the life cycle event trigger in ionic 4

Screenshoot: http://prntscr.com/oatlru [edit account page code ] , http://prntscr.com/oatlvz [My account page]

Hi Please go through it. It may help you
In summary, these are the events:

  • ionViewDidLoad : Fired only when a view is stored in memory . This event is NOT fired on entering a view that is already cached. It’s a nice place for init related tasks.
  • ionViewWillEnter : It’s fired when entering a page, before it becomes the active one. Use it for tasks you want to do every time you enter in the view (setting event listeners, updating a table, etc.).
  • ionViewDidEnter : Fired when entering a page, after it becomes the active page . Quite similar to the previous one.
  • ionViewWillLeave : Fired when you leave a page, before it stops being the active one. Use it for things you need to run every time you are leaving a page (deactivate event listeners, etc.).
  • ionViewDidLeave : Fired when you leave a page, after it stops being the active one. Similar to the previous one.
  • ionViewWillUnload : Fired when a view is going to be completely removed (after leaving a non-cached view).

Reference : https://ionicframework.com/blog/navigating-lifecycle-events/

1 Like

None of the event work when back from page to tab

my my-account tab

ionViewWillEnter() {
    this.getUser();
    console.log('ionViewWillEnter ')
  }

    ionViewDidLoad() {
    console.log('ionViewDidLoad ')
    }
    ionViewDidEnter() {
    console.log('ionViewDidEnter ')
    }
    ionViewWillLeave() {
    console.log('ionViewWillLeave  ')
    }
    ionViewDidLeave() {
    console.log('ionViewDidLeave   ')
    }
    ionViewWillUnload() {
    console.log('ionViewWillUnload    ')
    }

Check the bellow demo

I may be wrong.
What I understood is.

Your tabs is in one container .
Now when you clicked on Edit Profile you are moving from one container to another container.
So once you come back try to call methods in container and not in tabs.

I think you are right but if i redirect to different tabs page it works perfectly. In my situation its not working with the last page.
is there any way how i can achieve what i want to do.

image

Some Possible Solutions Can be

1.If on Edit Profile Page you are saving data on server once updation in profile done. Then you can access it again once you redirected to My account Page by calling api.

2.If its working with all pages then check router configurations

  1. I m doing that but the issue is when i came back from edit page its not triggering any event, so when it it come back from edit page api call is not made by the app and the data not updated.

Same type of situation:
Lets say a news app

Page 1: List of news
Page 2: Single news

When you go to Page 2 from Page 1 and the back to page 1 by pressing any back button the content of page not refreshing.

1.When you clicking on back button and redirected to Page 1 I think its not reloading. It just showing cached copy

2.If you use routing and load it fresh I think that time it can trigger events

On back button try to routing.

image

Able to fix the issue with this.

2 Likes

Hi @rakesh_appycodes

I know you have solved this issue but I am having this exact issue at the moment and couldn’t solve it with your proposed solution. Some questions I have:

  1. Can you show us the app routing definition?
  2. Is the Edit Account form page setup as its own module?

Thanks

Not that anybody need care about my opinion, but for what it’s worth, I think lifecycle events should not be (ab)used to solve the general problem of “displaying stale data”. What people tend to do:

interface Profile {
  name: string;
 // ...
}
class ProfileService {
  profile: Profile;
}
class ProfileDisplayPage {
  profile: Profile;
  constructor(private profiler: ProfileService) {}
  ngOnInit(): void { this.profile = this.profiler.profile; }
}
class ProfileEditPage {
  profile: Profile;
  constructor(private profiler: ProfileService) {}
  updateProfile(): void { this.profiler.profile = this.profile; }
} 

…then they ask “how do I force reloading of ProfileDisplayPage?”

What I do is to leverage RxJS to solve the problem of “how do I ensure that updates propagate easily and efficiently across my app?”:

class ProfileService {
  profile$ = new BehaviorSubject<Profile | null>(null);
  watchProfile(): Observable<Profile | null> { return this.profile$; }
  peekProfile(): Profile | null { return this.profile$.value; }
  pokeProfile(profile: Profile): void { this.profile$.next(profile); }
}
class ProfileDisplayPage {
  profile$: Observable<Profile | null>;
  constructor(private profiler: ProfileService) { this.profile$ = profiler.watchProfile(); }
}
class ProfileEditPage {
  profile: Profile;
  constructor(private profiler: ProfileService) { this.profile = profiler.peekProfile(); }
  updateProfile(): void { this.profiler.pokeProfile(this.profile); }
}

There are a myriad of options for accessing Observables from a template. Many of them involve memory leaks or overly verbose boilerplate. Two that don’t are the AsyncPipe and NetanelBasal’s ngx-take-until-destroy.

I frequently think in terms of “WORM (Write Once / Read Multiple) brokers”, where a resource has many readers and a single writer. The broker in this case is the ProfileService, which is injected by anybody interested in the Profile resource. It exposes three operations: watch, peek, and poke. Readers who want updates want watch. Transient readers that don’t care about updates can use peek. Writers generally take a snapshot with peek, modify it, and push the updates back with poke.

All of this happens with no additional code on the part of readers, no dependencies on the vagaries of framework internals (such as what lifecycle events fire when on what UI components), and no wasteful performance hits (such as you see with “solutions” to this problem that completely rerender a bunch of irrelevant stuff, often via action-at-a-distance).

It is also easy (and transparent) to add network and/or backing on-device storage to ProfileService. Nobody outside that class has to know or care when or how external forces collude to bring fresh data.

4 Likes