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

The cancel token is severely lacking in basic functionality #2

Open
dead-claudia opened this issue Jun 2, 2018 · 1 comment
Open

Comments

@dead-claudia
Copy link
Owner

Things it needs:

  1. Synchronous inspection. (If a cancel token has already been invoked, it shouldn't even attempt to run a worker method.)
  2. Synchronous cancellation.
  3. "Throw if cancelled", "resolve on cancellation", and "reject on cancellation".
  4. Wrapping a generator to work like an async function, but bail on cancellation (while also notifying the generator).
@dead-claudia
Copy link
Owner Author

dead-claudia commented Jun 2, 2018

It might be better if I just roll my own dedicated CancelToken class to hold all the methods, and make this have something like this instead (basic implementation sketch):

// This holds all the real state
class CancelController {
  constructor(init) { ... }
  get isCanceled() { ... }
  get token() { ... } // memoized
  cancel() { ... }
  cancelAsync() { ... }
}

// Proxy for the controller, to provide privacy. Not directly exposed.
class CancelToken {
  constructor(ctrl) { ... }
  get isCanceled() { ... }
  get promise() { ... } // memoized
  throwIfCanceled() { ... }
  addCancel(func) { ... }
  removeCancel(func) { ... }
}

For compatibility, aborted and onabort should also be accepted in the API, in case someone uses a weird Abort{Signal,Controller} polyfill for some reason (and in case this gets ported to the browser, where that could legitimately happen).

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

No branches or pull requests

1 participant