Re: [whatwg/fetch] Editorial: Reword how-to section to explain how to use callbacks & controller (PR #1614)

@domfarolino commented on this pull request.



>  </dl>
 
-<p>When invoked, the <a for=/>fetch</a> operation returns a <a for=/>fetch controller</a>. The
-controller is used for performing actions on a fetch operation that has already started, such as
-<a for="fetch controller" lt=abort>aborting</a> the operation by the user or page logic, or
-<a for="fetch controller" lt=terminate>terminating</a> it due to a browser-internal circumstance.
-
-
+<p>Apart from the callbacks to handle responses, <a for=/>fetch</a> accepts additional callbacks
+for advanced cases.<a for=fetch><i>processEarlyHintsResponse</i></a> is intended specifically for
+<a for=/>responses</a> whose <a for=response>status</a> is 103, and is currently handled only by
+navigations. <a for=fetch><i>processRequestBodyChunkLength</i></a> and
+<a for=fetch><i>processRequestEndOfBody</i></a> notify the client of request body uploading
+progress.
+
+<p>Note that the <a for=/>fetch</a> operation runs <a>in parallel</a>, and it usually posts

Hmm, can we make this more specific by mentioning that typically the Fetch operation is intended to be called from the main thread[^1], but that its _inner machinations_ break off in parallel at some point? I think we can also say that in this scenario, _by default_ the response is processed _back_ on the main thread via the client's event loop. (I like "by default" instead of "usually," since I think it clarifies the forks a little).

[^1]: I've seen feedback like https://github.com/fedidcg/FedCM/issues/261#issuecomment-1268064407 given at least twice so it might be good to codify this here in the description of how Fetch works with multiple eent loops.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1614#pullrequestreview-1342735857
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1614/review/1342735857@github.com>