Proposal: Use AbortController instead of the whenClosed() api on open()

[rmja]

I'm submitting a feature request

Current behavior:
The current interface for open() has a nested promise to allow for cancellation of the dialog and wait for the result.

Expected/desired behavior:
An example of the current proposal for AbortController for the use in fetch() is here:. A similar example for dialog.open() could be:

let controller = new AbortController();
let result = dialog.open<TResult>({/* the usual stuff */,abort: controller.signal})

// To cancel the dialog:
controller.abort();

// Otherwise:
let output = result.output; // is of type TResult

The AbortController is supported in the upcoming releases of Firefox and Edge.

[StrahilKazlachev]

I vote not to integrate till TC39 clears the cancellation topic.

But here is something with which we can start preparing:

• in both the WHATWG spec and ES proposals a cancellation of async process results in the rejection of the Promise with a dedicated Error - we don't do that currently by default, it is configurable though.
• currently there are 3 points that are considered as cancellation points:
  1. canActivate resolving to false - DialogService.prototype.open execution has been interrupted.
  2. canDeactivate resolving to false - DialogController.prototype.close execution has been interrupted.
  3. calling DialogController.prototype.cancel or DialogController.prototype.close(false) - closes the dialog saying it was cancelled.

For me i. and ii. are legit cancellation points. iii. is different, it does not interrupt an ongoing process - just conveys an intention of dismissal when the dialog transitions from one state to another(from open to closed).
An interesting scenario - when you call DialogController.prototype.cancel or DialogController.prototype.close(false) and canDeactivate returns false - you cancel a cancellation.