Feature Request - Means to keep overlay between multiple dialogs

[timfish]

I'm submitting a feature request

Current behavior: If you display one dialog after another, there is a brief time where the overlay disappears before the next dialog is displayed.

Expected/desired behavior: There could be a way to keep the overlay between dialogs. This could probably be separate to this library but I'm sure others will find it useful

dialogService.showOverlay(async() => {
  const result1 = await dialogService.open({ ... }).whenClosed();

  if(result.output) {
    // more
    const result2 = await dialogService.open({ ... }).whenClosed();
  }
});

[StrahilKazlachev]

For me this is entirely up to the Renderer. We can experiment using only one overlay in the Renderers implementations. Additional overlay APIs does imply that the one showing it will have to hide it.

[timfish]

How would you tell the renderer that you want to keep the overlay even when no dialogs are in the stack?

I suppose you could always add an invisible dialog at the start and remove it in a finally once all your other dialog operations are complete?

[StrahilKazlachev]

So your scenario is something like conditional sequence of dialogs? Whether the next shows depends on the result of the previous, but a result is available after a dialog closes.

[timfish]

Yes, conditional sequence of dialogs where I want keep the overlay between the dialogs to:

• stop the visual flash of removing and re-adding the overlay
• block the main app context

Currently this can be achieved by opening the subsequent dialogs from the previous dialog but this is a terrible pattern as the logic get spread through dialogs which then can't be reused for other purposes.

[Alexander-Taran]

looks like a wizard scenario. do you have branching inside this chain? if not could you maybe instead of resolving after first dialog move on to next step? And conditionally render steps dialog?

[timfish]

There are branches yes.

I did at one point have a single dialog that loaded steps though a <compose> but as soon as it started having conditional steps and branches I took a step back and noticed I was starting to create my own dialog renderer. 😆

Our overlay backdrop uses a CSS filter on the main content so fixing the flash of un-overlayed content was as simple as:

export class Overlay {
  public static async show(work: () => Promise<void>): Promise<void> {
    // using a different class so the dialog renderer doesn't remove it
    document.body.classList.add('ux-dialog-open-alt');
    try {
      await work();
    } finally {
      document.body.classList.remove('ux-dialog-open-alt');
    }
  }
}

Overlay.show(async() => {
  // do dialog work here
});

[Alexander-Taran]

Seems like not a general case for framework. Maybe it could be an extention of dialog plugin. But then again how one would generalize the work done in wizard?

@timfish do you think it can be closed?

[davidGrocerKey]

was this or something similar ever implemented? Even when I put a timeout before closing the first dialog there is a blink because it looks like the class 'active' is disappearing from the overlay before the overlay itself disappears

[davidGrocerKey]

I actually just found that setting contoller.settings.ignoreTransitions to true solves this problem