Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rmja opened this issue Oct 19, 2017 · 1 comment
Open

Comments

@rmja
Copy link

rmja commented Oct 19, 2017

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
Copy link
Contributor

StrahilKazlachev commented Oct 19, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants