Reload current page / ionViewWillEnter [solved]

I have a modal that changes and API variable. And this variable is used to fetch server-side information. I usually load this data on ionViewWillEnter function.

Is there a way to call that function or trigger that event after selecting an element on the modal / selector.ts ?

Solved by using Angular’s Events.

On my selected() function:

  selected(){
    this.api.changeSelectedData(this.selectedIds)
    this.events.publish('api:data', Date.now());
    this.dismissModal()    
  }

And then on each page’s constructor:

 constructor(public service:BulletinService, public events: Events) {
    events.subscribe('api:data', (time) => {
      this.ionViewWillEnter();
    });
   }

I would like to urge future readers stumbling across this thread to read this post before adopting the strategy marked as the “solution” here.

I consider manually calling lifecycle events an antipattern, as a violation of the principle of least surprise. Additionally, anything that can be done with Events can be done better in many ways (more expressive, less prone to typos, more self-documenting, more accurately targeted) with Observables.

Creating a “load()” method and calling It instead of ionViewWillEnter is a good enough solution in your opinion ?
Thanks.

It’s better than abusing lifecycle events, but the post I linked describes exactly the situation you seem to have here: data is changing and representations of that data need to reflect those changes.

When the data holder exposes the data as an Observable, it is clear instantly that it may change over the course of an app run, and therefore anybody who cares about that can subscribe to that Observable and receive exactly what it wants: the freshest copy of the data as a business object, in the same manner it is received initially. Additionally, for transient consumers (like, for example, a short-lived modal that only cares about “what is the current state of affairs”), a snapshot can be provided.

I’ll take a look at your post ASAP, but Its not the data itself that changed. It’s the configuration inside an API class I created that is used to fetch the data. So, I need to fetch the new data based on the configuration the user choose. Something like that.

I have an “GET /api/option/{id}” to receive a list of “schedules” lets say. When user changed the {id}, I need to fetch the new schedules.

So the observable would be in the {id} not on the {schedules} data.

Anyway, I might be saying crap, cause I didnt read the post yet. Anyway thank you for your answer and contribution.

This was a gigantic stumbling block for me when I started with AngularJS: I was always trying to have and follow a thread of program execution; I was thinking in terms of execution context and program counters and whatnot. I found it an extremely liberating “aha” moment when I let go of all of that and started thinking backwards:

  • I have a page or component that is presenting data to a user and responding to user interactions with it
  • I write a business-layer interface encapsulating exactly the format of information that that page or component would like to consume
  • If necessary, I then think about what sort of API would make sense to make providing that business-layer object doable, in as easy a manner as possible
  • Then I write a service that bridges between the last two tasks: it exposes an Observable<BusinessThingy> if it makes sense to have an app-wide sense of “current state” and also has various changeWhichThingyWeAreMogrifying methods that indirectly (may) result in API calls and emissions from the exposed Observable. If there is no app-wide state, then getASpecificThingy could return new Observable<BusinessThingy>s for each call.

So, pages and components have only one or maybe two tasks: display a BusinessThingy and report actions being taken to it. Services are responsible for being the single source of truth for dealing with all things backend, and exposing them either as Observables or snapshots of business-layer objects.

If SchedulesPage cares only about schedules, all it should do is subscribe to an Observable<Schedule[]>. What determines which schedules get emitted by that Observable? SchedulesPage doesn’t care.

If SchedulesPage needs to display something like “schedules for mary student”, then the object it subscribes to needs to include both a Schedule[] and some sort of profile information that includes the name “mary student”.

The action of load shouldn’t be done by the page, but by the service.

You’re basically advising people to send their car to the junkyard and buy a new one whenever the “check engine” light comes on. location.reload causes the browser to completely reinterpret the entire app - it’s an extremely heavy operation that is, at least in my experience, never warranted in an Ionic or Angular app.

2 Likes

You made this post extremelly helpful and this should be refferenced to avoid mistakes from other developers, just like I did. It’s a different perspective handling data with Angular, and you’re completly correct when you say its a liberating “aha” moment!

Thank you very very much!