Re: [w3ctag/design-reviews] AbortSignal.timeout() (Issue #711)

A small helper that uses `AbortSignal` primitives could also help clean this up:
```js
const withTimeout = (signal, timeout) =>
  AbortSignal.any([signal, AbortSignal.timeout(timeout)]);

...

const controller = new AbortController();
fetch(url, {signal: withTimeout(controller.signal, 8000))};

// vs.

const controller = new AbortController({ timeout: 8000 });
fetch(url, { signal: controller.signal });
```

The `timeout` option seems reasonable to me, if DOM editors are supportive. I agree that the `AbortSignal` factory methods (`.timeout()` and proposed `.any()`), while sufficient (% perhaps timeout control), are not optimal for the case where a new controller is also needed. Avoiding the helpers here might be worth it.

Prior art on other platforms: .NET's `CancellationTokenSource` has a [constructor timeout parameter](https://docs.microsoft.com/en-us/dotnet/api/system.threading.cancellationtokensource.-ctor?view=net-6.0#system-threading-cancellationtokensource-ctor(system-int32)) and Go's context has a [`WithTimeout`](https://pkg.go.dev/context#WithTimeout) function, both of which provide similar functionality. Also, if necessary, `AbortController` could eventually be extended with methods to manipulate the timeout, similar to [`CancellationTokenSource.CancelAfter()`](https://docs.microsoft.com/en-us/dotnet/api/system.threading.cancellationtokensource.cancelafter?view=net-6.0).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/711#issuecomment-1184627139
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/711/1184627139@github.com>