Consider to add "resolveAtIdleTime" to RequestInit

[smaug----]

During TPAC there was discussion about having lower priority fetches. The idea was something more complicated, but perhaps we could actually start by just hinting when fetch()'s promise should be resolved.
Idle time could work reasonable well for many cases, though perhaps there would need to be also some max timeout to ensure it gets resolved at some point.

And since XHR is very commonly used, something similar could be added there too.

(Just recording this idea here, so that I don't forget it.)

@spanicker

[yoavweiss]

This seems related to other proposals on that front, most notably priority hints.

/cc @domfarolino @addyosmani

[domfarolino]

Definitely seems related to PH agreed, though seems to cover a superset of the problems PH is geared toward (given that resolving in idle time could mean delaying resolution due to either network or main thread contention). I think the networking-priority portion of this would be best suited for Priority Hints though.

Did you have any specific cases in mind where this might be most helpful? Currently I’m looking for as many network-contention-heavy scenarios as I can where user-supplied priority hints may result in a perceivable win, so I’m open to hearing anything you may have in mind.

[smaug----]

Priority hints is about the networking side. This is more about the stuff discussed TPAC about handling network responses at lower priority.

[yoavweiss]

Is there a reason we can't define a single API/developer-signal to implement both network priority and response handling?

[smaug----]

Sure we can. As I said in the initial comment, I just filed the issue to record the idea somewhere before I forget.

[spanicker]

Is there a reason we can't define a single API/developer-signal to implement both network priority and response handling?

I cannot think of a reason to not tackle both the problems (other than scope), makes sense to consider both aspects. However the response handling priority is a bit different: it needs a way to pass a priority (that won't always necessarily be the same as fetch priority), that can potentially be updated (eg. something was fetched preemptively to prepare next screen, but now the user has explicitly requested it or vice versa).

Ability to specify priority for fetch promise resolution (and something for xhr) makes sense to me.
However I'd like to see better support for priorities than just "idle".
I'll think about this more and loop back with a proposal for priorities.
(I agree with Yoav that those same set of priorities should also be able to be hinted on the fetches themselves)

[yutakahirano]

Just having a general function, say waitForIdle, looks simpler to me. We can use it with timeout fairly easily.

function wait(ms) { return new Promise(res => setTimeout(res, ms)); }
const timeout = wait(100);
const resp = await fetch(...);
await Promise.race([waitForIdle(), timeout]);

This actually executes tiny code when it's not idle, but I think we can bear with it.

[ken0x0a]

I guess Promise.race doesn't actually abort fetch ... Is it still working in background, isn't it?

[annevk]

See also #436.