[pending-task] Cancellation mechanism

[nolanlawson]

The proposal says:

This proposal does not cover cancelling tasks. Similar to Promises, this proposal assumes that task cancellation is best done by the task initiators with an AbortSignal. Objects being notified of a task shouldn't necessarily be able to cancel it.

We (LWC) were looking over this proposal today, and one observation was that there are, occasionally, cases where the event receiver may want to cancel the promise.

For example, you might imagine a parent component showing a loading spinner representing the loading state of its child components (i.e. to show one spinner instead of multiple). That parent component might have an "X" (or "Cancel") button. When the user clicks the button, all child components should cancel their promises.

If such a scenario is considered out-of-scope for this proposal, then it may be worth thinking about the recommended alternative. E.g.:

• Should the parent disconnect its children and expect the children to cancel their promises in their disconnectedCallbacks?
• Should prop-drilling or the Context API be used as a communication mechanism?

Otherwise, maybe there should be an optional abort callback that could be attached to the PendingTaskEvent? Something like:

interface PendingTaskEvent extends Event {
  complete: Promise<void>;
+  abort?: () => void;
}

/cc @caridy @leobalter

[justinfagnani]

I see the desire for this, but I think it's worth considering the existing ways to accomplish cancellation and whether adding more is good or not, and whether cancellation should be tied to pending-tasks - are there cases where you want to cancel that wouldn't use pending-task?

I can think of two main ways to do this now:

1. Use a concrete scheduler API. If there is some overarching controller of tasks, there's a good argument that tasks shouldn't just be implicitly created under it with minimal control (cancellation), but that tasks should be created in coordination with the scheduler so it can fully control them (pause/resume, logging, progress, debounce, etc.)
2. AbortSignal. This is already a way to cancel and can be thread into other APIs like fetch(). The interoperability here is compelling to me.

Both of these could be provided via either a context or properties.

One thing that's interesting about AbortSignal is the potential to compose them: An async operation could consume one at a standard context key (ie, 'abort-signal' - which could be a small community protocol itself), and any ancestor that wanted to cancel could provide it, and could also consume a signal from above and combine it with its own additional signals to create nesting cancellation.