Handle platforms where AbortController is not supported, instead of asking for (ineffective) polyfills

[peaBerberian]

Hi,

tl;dr: The "idea" I'm proposing here is to actually fix an issue in multiple popular media players that is provoked indirectly by a requirement of tanstack-query: the presence of the AbortController API on the platform.

Sadly all AbortController polyfills that we know of are not really "functional", in that they do not provoke the expected behavior on the fetch API, its principal consumer, including any of them in an application has an important negative effect on media players.
I'm thus asking for tanstack-query to allow AbortController to not be defined on the current platform.

Explanation:

I'm a library developer for a web media player.
An application depending on this player was having multiple issues after relying on tanstack-query.

They target some old devices which have access to the fetch API, but not to the AbortController API (e.g. smart TVs, game consoles).
Because they saw errors about that object being undefined when relying on tanstack-query, they looked at the tanstack-query API documentation on the subject which proposes, and link to, several AbortController polyfills.
They then imported one of those, saw that tanstack-query worked, and then thought that everything was OK.

But actually those polyfills have a big downside that is difficult to see at first, they don't actually provoke "real" cancellation on the fetch API, which is the main consumer for that API. In a way they don't really fulfill their main goal.

This creates an important problem for some library developers, including those developing media players, like me.

We frequently have large chunks of media data to download and we thus rely on a functional cancellation mechanism to ensure a good experience. Let's for example imagine that the user's bandwidth drastically drops while loading 4k UHD video content: here we want to be able to cancel the request and request a lower video quality instead.
Because cancellation is very important, we check that both fetch and AbortController are available on the platform before choosing that API. If it's not, we fallback on an XmlHttpRequest (we prefer fetch for other reasons, but cancellation is very important for us).

This is the case in our player, but also in the much popular shaka-player and hls.js players, which all have similar logic where we check both for fetch and AbortController and if any of them is not defined, we fallback to an XHR.

Due to an AbortController polyfill being imported, all those players will now think they are able to rely on a cancellable fetch, and thus lead to a worse experience for end users, without application developers noticing right away.

I'm talking only about media players because that's what I know, but I'm sure there are other use cases where a functional AbortController + fetch API is important.

Idea:

We ask applications to avoid including an AbortController polyfill for now, but doing this prevent them from using tanstack-query.

What I propose for tanstack-query is to still work even if AbortController` is not available in global scope, or perhaps to let the application define one if that would be preferable for you.

[TkDodo]

We only target platforms that support AbortController, sorry. We had some runtime checks in v4 when we supported older browsers, but not anymore in v5. It’s a trade-off in favor of simplicity and bundle-size vs supporting (very) old environments.

I think the best thing you can do is use a polyfill that actually works, or make your check detect such polyfills and don’t use fetch if AbortController is polyfilled.

[peaBerberian]

Thanks for the quick response.

I think the best thing you can do is use a polyfill that actually works

Sadly I don't think this is really possible as this would mean that the native fetch API on that platform listens to the given AbortSignal polyfill.
There's a low probability that the browser developer implemented that logic for a not-yet released API.

An alternative would be for them (the application relying on our library) to also polyfill fetch so that it e.g. relies on XHR behind the hood (which also supports cancellation) but also there we lose some advantage of the actually-native fetch API.

---

The better alternative we were thinking about, that you also proposed, was detecting on our side that the current AbortController API was a polyfill and not use fetch in that case, but this could mean that this AbortController API cannot be monkey-patched easily (for devices that do have it, e.g. to spy on it or doing some plugin or whatnot), we generally avoid such complex and somewhat developer-hostile behaviors.
But I think this will be what we'll end up doing sadly (we'll see on our side what we can do).

---

Also just a side-note, (in an improbable case where I can change your mind on this :D) this is not only "very old environments": Samsung 2019 TV models, LG 2019 TV models most (all?) XBoxes and some french ISP's devices all seem to not have the AbortController API from that application's tests.
Those are still frequently-used and somewhat recent consumer devices.