fetchLater() API (previously: PendingBeacon API)

[mingyc]

Request for position on an emerging web specification

• WebKittens who can provide input:

Information about the spec

• Spec Title: Pending Beacon
• Spec URL: https://wicg.github.io/pending-beacon
• GitHub repository: https://github.com/WICG/pending-beacon
• Issue Tracker (if not the repository's issue tracker):
• Explainer (if not README.md in the repository): https://github.com/WICG/pending-beacon/blob/main/README.md

Design reviews and vendor positions

• TAG Design Review: Early Design Review: Pending Beacon API w3ctag/design-reviews#776
• Mozilla standards-positions issue: fetchLater() API mozilla/standards-positions#703

Anything else we need to know

We would like to have feedback from WebKit about this API before finalizing its shape and behavior.

[othermaciej]

How does this relate to Beacon API? Why is it a separate spec and not an extension of Beacon API?

Also on first glance, this is a lot more complicated than Beacon API itself, which is just one method, not a class hierarchy of multiple interfaces. Is the extra complexity actually necessary? At first glance, it's not obvious why it is necessary to have all these ways to customise a "pending" beacon when regular beacons don't need these things. (If Beacon API itself is underpowered, then that would be more reason to extend the Beacon API instead of making an orthogonal API).

[othermaciej]

Also needs to be examined to see if it enables cross-site tracking.

[mingyc]

I'll try to answer some of your questions. Feel free to add more under https://github.com/WICG/pending-beacon/issues so that more pepole can discussion

How does this relate to Beacon API? Why is it a separate spec and not an extension of Beacon API?

At the beginning there were discussions around the following options

1. extending navigator.sendBeacon() with a flag: the use cases went beyond a single flag. They need to be able to update what will be sent and/or cancel it. But the existing sendBeacon() semantic doesn't support it.
2. adding a new declarative DOM API: but scripting will be neccessary to fill data.
3. [chosen] adding a new stateful JS API.

1 and 2 have its own drawbacks, and the 3rd one is chosen. @fergald might be able to provide full context.

Also on first glance, this is a lot more complicated than Beacon API itself, which is just one method, not a class hierarchy of multiple interfaces. Is the extra complexity actually necessary?

It's answered in WICG/pending-beacon#59. In short we would like to provide more type safety on compile time.

At first glance, it's not obvious why it is necessary to have all these ways to customise a "pending" beacon when regular beacons don't need these things. (If Beacon API itself is underpowered, then that would be more reason to extend the Beacon API instead of making an orthogonal API).

[mingyc]

Also needs to be examined to see if it enables cross-site tracking.

The scope of this API proposal doesn't include cross-site tracking.

Also cc @fergald

[mingyc]

@othermaciej pinging for any updates or comments

[mingyc]

Friendly pinging again for your position.

How does this relate to Beacon API? Why is it a separate spec and not an extension of Beacon API?

In addition to the above reasons from #85 (comment), we further added a section to explain why not extending the Fetch API (Beacon API is roughly equivalent to Fetch keepalive for Post-only request). Simply put, our requirements are beyond the scope of Fetch.

[marcoscaceres]

I’m also concerned about adding an entirely new API.

They need to be able to update what will be sent and/or cancel it. But the existing sendBeacon() semantic doesn't support it.

sure, but I’m wondering if all possible options have been explored for extending the existing spec? For instance, perhaps a third argument could be added to sendBeacon() accepting a dictionary that:

• takes an optional AbortController’s signal
• takes an optional http method name, so to support POST.
• takes the timeout.

Perhaps something like the above could addressed the use cases without needing an entirely new API?