IonViewWillEnter doesn't get Triggered

Ionic Framework Ionic Angular
1

Hi,

So I have 3 pages (2 normal view pages and 1 modal page). One of the 2 normal view pages (page A) opens the modal page, and the modal page calls the other normal view page (B).

There’s a button in B that updates the database and goes back supposedly to A. I need to make A be updated inline with the updated database such that after pressing the button in B, it calls again my APIs deployed in a web server. I am aware of ion view page lifecycle, and I think IonViewWillEnter/IonViewDidEnter might help me. However, upon using either of the two, it doesn’t get triggered after popping from B.

Any help?

Here are the snippets of the typescript files.

Normal View Page (A) that calls the modal. Method loadData is the call to API service

ionViewWillEnter() {
this.loadData();
}

loadData(){
this.user = this.dataService.getParamData();
this.hcf_id = this.user.hcfId;
this.sub = this.roomService.getAllRooms(this.hcf_id).subscribe(e => {
this.rooms = e;
});
this.sub2 = this.roomService.getAllRoomByType(this.hcf_id, 1).subscribe(e => {
this.commonRooms = e;
});
this.sub3 = this.roomService.getAllRoomByType(this.hcf_id, 2).subscribe(e => {
this.functionalRooms = e;
});
}

async showDetails(response: Room){
const modal = await this.modalController.create({
component: ModalPage,
componentProps: {
room: response
}
});
modal.present();
}

Modal page that calls normal view page B

closeModal(){
this.modalController.dismiss();
}

editLPGRP(room_id: Number){
this.dataService.pushTempData(this.lpgrpGen);
this.navCtrl.navigateForward(‘lpgrfgen’);
this.closeModal();
}

Normal View Page B which has a button to update the database thru API and pops back to A

calculateFunctionality(){
this.lpgrpAssessmentService.updateGenAssessment(this.lpgrpGen).subscribe();
this.navCtrl.pop();
}
else{
alert(“Please finish assessing all the elements before calculating functionality!”);
}
}

2

While you wait for better answers, I’m going to try to convince you to avoid lifecycle events here entirely.

To me, the contract of lifecycle events begins and ends with the notion that they are called in pairwise fashion: willEnter won’t get called twice without an intervening willLeave and vice versa. Anything beyond that is completely at the discretion of the framework. If it decides it wants to cache pages for performance based on some phase-of-the-moon calculation, fine. If it decides it needs to evict everybody from said cache for whatever reason, again, none of my business.

So the only thing they should be used for is acquiring and releasing resources (such as subscribing and unsubscribing to Observables).

I would therefore rename loadData to something that indicates that it is subscribing to changes in whatever this data is, and do that. The actual changes to the data are largely already being propagated directly by your app code, which is great. It looks to me like getParamData is the only straggler. Observable-ize it and you should be good to go, regardless of when lifecycle events are called.

3

Should I still make the getParamData be of Observable type when it’s only a local service to pass around values to different pages?

Anyway, I’ll do what you have said regardless.

Thanks!

4

I would, because it allows all those different pages to get pushed any updates without having to do any extra work.