#887: Specification Review: FetchLater API

Visit on Github.

Opened Aug 28, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of Fetchlater API.

This is a proposal for FetchLater API. It is a system for sending beacons when pages are discarded, that uses a stateful API rather than having developers explicitly send beacons themselves.

Further details:

  • [✓] I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: BY Q4 2023
  • The group where the work on this specification is currently being done: whatwg/fetch
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
  • Major unresolved issues with or opposition to this specification: The PR is not approved yet.
  • This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify @mingyc, @fergald, @noamr

Discussions

Discussed Sep 4, 2023 (See Github)

Sangwhan: I have looked at this... I like it.

Dan: It's WICG .. it's BFCache ... It's WHATWG...

Sangwhan: if you have a document and user closes the tab... if you have a fetch in flight you can't know if it happened. So there is the beacon api... which didn't follow the fetch pattern. So they redesigned it... New name is FetchLater. Less confusing... It implies it's a delayed fetch but what it really does is add a guarantee... The part where I have questions is the use cases.. They provide a high level use but not a real application use - what kinds of user-facing functions would this be used for? It's clear what the telemetry use cases are... I don't see it as harmful.

Dan: adds complexity to the web platform - if it's only for telemetry ... then is it worth it?

Sangwhan: they could also use it in cases where they haven't finished sending the final state of the app back to the server - e.g. writing a form and therte is a heartbeat where it's saving your current progress... Some anti-patterns such as "do you want to close this tab?" blocking - could go away.

Sangwhan: will leave comment and speak to the requestor

Comment by @cynthia Sep 7, 2023 (See Github)

Discussed during plenary this week. API seems fine, but the naming is a bit strange, "fetch later" could be misunderstood as a deferred fetch, when what you are getting is a guaranteed fetch when the document is gone. We don't have any better suggestions, but just wanted to point out the possibility of misunderstanding.

Explainer could use a bit more spelling out what the user story is. I have some speculations on how this could be used, but that's wildly speculative. Could you add some problems this proposal solves?

Comment by @mingyc Sep 7, 2023 (See Github) 
"fetch later" could be misunderstood as a deferred fetch

The current PR (https://github.com/whatwg/fetch/pull/1647) actually calls the algorithm deferred fetching, I think it's intentional.

@noamr FYI

Explainer could use a bit more spelling out what the user story is. I have some speculations on how this could be used, but that's wildly speculative. Could you add some problems this proposal solves?

My bad that the linked explainer does not point to the entry explainer describing the overall goal. Please let me know if the problem description there is clear or not.

Also, I will try to include more story into the fetch later explainer.

Comment by @noamr Sep 7, 2023 (See Github)

Discussed during plenary this week. API seems fine, but the naming is a bit strange, "fetch later" could be misunderstood as a deferred fetch, when what you are getting is a guaranteed fetch when the document is gone. We don't have any better suggestions, but just wanted to point out the possibility of misunderstanding.

I don't really understand this comment. The fetch is deferred to when the document is gone/deactivated. It's called now, and processed at a later time.

Comment by @cynthia Sep 19, 2023 (See Github)

I don't really understand this comment. The fetch is deferred to when the document is gone/deactivated. It's called now, and processed at a later time.

To clarify the sentiment on the naming - it was about the ambiguity of "later" (which can be any time between now and whenever) when it's actually at the point of document destruct (which is much more narrow window than "between now and whenever").

Comment by @noamr Sep 19, 2023 (See Github)

I don't really understand this comment. The fetch is deferred to when the document is gone/deactivated. It's called now, and processed at a later time.

To clarify the sentiment on the naming - it was about the ambiguity of "later" (which can be any time between now and whenever) when it's actually at the point of document destruct (which is much more narrow window than "between now and whenever").

It's actually "any time between now and document destruct or the given timeout, as late as possible". I think "later" conveys this.

Discussed Oct 9, 2023 (See Github)

Dan: we had a reply 3 weeks ago.. clarifying naming

Sangwhan: fetch later means any time between now and destruct.. but in reality it's as late as possible.. I'm okay with this

Yves: Same. When we first reviewed this we were concerned they were exchanging state using get and they seem to have fixed this. Okay to close.

agreed to close - Sangwhan to leave closing comment

Comment by @cynthia Oct 10, 2023 (See Github)

It's actually "any time between now and document destruct or the given timeout, as late as possible". I think "later" conveys this.

Understood. Happy to move this forward in that case, thanks!