feat: add `didPresent` and `willPresent` methods for `ion-modal`

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request

The feature will allow users to know if the modal they have will begin being presented or is already present, similar to how onDidDismiss and onWillDismiss work.

Describe the Use Case

I have a sheet modal that I want to access via ModalController.getTop(). With this model ref, I want to access the setCurrentBreakpoint method and modify the current breakpoint of the modal. However, when I call it, nothing happens but there’s no error, exception, or warning being thrown either.

After some experimentation, I realized that I couldn’t use setCurrentBreakpoint until the modal is fully presented. However, I don’t have anything other than the present method to let me know if the modal is already present or not. In this instance, I’ve already called present in a service and I only want to know if the modal is already present, without calling present in the modal component, so that I can change the breakpoint depending on what’s happening in the component.

Describe Preferred Solution

The solution I would prefer would be something along the lines of onDidDismiss and onWillDismiss. Just a good old Promise that resolves when the condition is true.

Example:

const modal = await modalController.getTop() await modal.didPresent() await modal.setCurrentBreakpoint(1)

Describe Alternatives

No response

Related Code

No response

Additional Information

No response

[sean-perkins]

Thanks for the follow-up! Just getting back from vacation. Looking through your example code, your implementation looks great/as recommended.

I have created a documentation issue to track documenting patterns around this: https://github.com/ionic-team/ionic-docs/issues/2340.

In the interim of that issue being resolved; if others come across this issue and present multiple modals from a service and do not want to have many rxjs subjects for each modal type; you can emit additional metadata from the subject that can be later filtered on in your implementation.

For example:

@Injectable()
export class ModalService {
  isModalPresent$ = new Subject<{ id: string >}();

  constructor(private modalCtrl: ModalController) {}

  async presentModal() {
    const modal = await this.modalCtrl.create(...);
    await modal.present();
    this.isModalPresent$.next({
      id: 'myModal'
    });
  }
}

this.modalService.isModalPresent$
  .pipe(
    filter(res => res.id === 'myModal')
    take(1)
  )
  .subscribe(() => {
  // Your logic here
});

Also, if there is any chance that your modal is presented before your component is mounted/the subscription is set, you may want to consider a BehaviorSubject, so that you can get a reference to the value even after it was emitted (this will require clearing the subject/emitting false when the modal is dismissed).

I am going to close this feature request for now. As we document this pattern and as requirements change in the future, we will continue to evaluate if more helper methods for event listeners makes sense or if existing library patterns better solve those constraints.

Thanks!

[sean-perkins]

@rhenriquez28 follow-up after discussing with Liam.

Both the willDismiss and didDismiss method were introduced to the public API so that developers could easily access the data and role values returned from the overlay.

With willPresent and didPresent, these events do not return information back to the developer that isn’t already accessible from awaiting the calling function.

For example:

async function presentModal() {
  const modal = this.modalCtrl.create(...);
  // modal.willPresent 
  await modal.present();
  // modal.didPresent
}

Since you can create a modal and present it separately, the subject approach is likely the ideal implementation pattern for Angular applications.

@Injectable() 
export class MyService {

  doThing$ = new Subject<void>();

  constructor(private modalCtrl: ModalController) {}

  async presentModal() {
    const modal = await this.modalCtrl.create(...);
    await modal.present();
    this.doThing$.next();
  }

}

After listing these examples, it feels like this is a documentation issue. The benefits of introducing didPresent/willPresent methods, dilutes the reasoning of the original didDismiss/willDismiss and also doesn’t provide extra value/context that isn’t already available (through slightly different usage patterns).

Do you have any feedback on benefits of those methods would provide that aren’t easily covered with these alternatives? If not, I’d be happy to document some of these patterns.