Custom ion-alert, issues with transitions + providers


#1

I needed a custom version of ion-alert that would use a ViewChild (instead of form elements as the body of the alert). I copied ion-alert and made a few tweaks - instead of taking input type and stuff, it just takes a component (similar to ion-modal).

Everything is perfect except it doesn’t perform the transitions, so you can’t actually see the alert. I can’t understand how the transitions are even fired with ion-alert, the only code seems to be this:

    config.setTransition('alert-pop-in', AlertPopIn);
    config.setTransition('alert-pop-out', AlertPopOut);
    config.setTransition('alert-md-pop-in', AlertMdPopIn);
    config.setTransition('alert-md-pop-out', AlertMdPopOut);
    config.setTransition('alert-wp-pop-in', AlertWpPopIn);
    config.setTransition('alert-wp-pop-out', AlertWpPopOut);

I don’t see where these class names (?) are connected to the creation and dismiss events.

In my “copy” of ion-alert, if I explore the DOM, I can see my <popup> element in place of <ion-alert>, but the opacity stays at 0 because these transitions are not being executed.

I posted some code here:

Another issue is how to pass the [providers] from the app.component into the ViewChild so that child component doesn’t have to declare separate versions of the providers.

Any help would be greatly appreciated!


#2

Use a modal. The alert is not intended to be reformatted. You have much more control over both formatting and the handler if you use a modal.


#3

I was using a modal before but basically I’m trying to get all the design elements of an alert, including the transition animation… so why not make it an alert. It basically works, I just don’t get how these animations are being fired with a regular alert.


#4

Because if you do something with the framework that driftyco has repeatedly said they don’t support, you run the risk of framework updates introducing changes that are breaking changes only for you. Also, unless you’re willing to test on a wide variety of real devices at every step of the process, you need to keep your formatting “inside the box,” to ensure it’s likely that your app will render correctly across devices. You need code that works across platforms, which means that specialization away from documentation is risky.


#5

Yes, there is a risk of breaking, although as it stands, this version is pretty self-sufficient. As with any module that is specific to Ionic, a simple change could break this. Same could be said of super-tabs or other modules.

I figured out the issue with the transitions, needed this code:


    config.setModeConfig('ios', { popupEnter: 'popup-pop-in', popupLeave: 'popup-pop-out' });
    config.setModeConfig('md',  { popupEnter: 'popup-md-pop-in', popupLeave: 'popup-md-pop-out' });
    config.setModeConfig('wp',  { popupEnter: 'popup-wp-pop-in', popupLeave: 'popup-wp-pop-out' });

Apparently ionic normally has a MODE_xyz object that it feeds into setModeConfig for each platform. This is then translated to at transition name by the getTransitionName function:

  getTransitionName(direction: string): string {
    let key = (direction === 'back' ? 'popupLeave' : 'popupEnter');
    return this._nav && this._nav.config.get(key);
  }

And that’s how the transitions work, which was my original question.

Any ideas on the how to pass the [providers] to the ViewChild would be great.