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

@annevk commented on this pull request.



> -
- <dt><a for=fetch><i>processResponseEndOfBody</i></a>
- <dd><p>Takes an algorithm that will be passed a <a for=/>response</a>. Indicates the network is
- done transmitting the response. This does not read <a for=/>response</a>'s
- <a for=response>body</a>.
+  <p>This is the most common way in which clients handle a <a for=/>response</a>, for example
+  <a lt="fetch a classic script">scripts</a> and <a lt="fetch a style resource">style resources</a>.
+  The <a for=/>response</a>'s <a for=response>body</a> is obtained in its entirety into a
+  <a>byte sequence</a>, and then processed by the client.
+
+  <p>To process a <a for=/>response</a> upon completion, pass an algorithm as the
+  <a for=fetch><i>processResponseConsumeBody</i></a> argument of <a for=/>fetch</a>. The given
+  algorithm is passed a <a for=/>response</a> and null, failure, or a <a>byte sequence</a>.
+  The second argument would be null if there was a <a>network error</a>, failure if there was an
+  error while downloading, or a <a>byte sequence</a> representing the successfully obtained
+  <a for=response>body</a>.

I see what you mean now, but that's not entirely correct. A network error has a null body and therefore it's null, but other responses can have null bodies as well.

In fact, https://fetch.spec.whatwg.org/#ref-for-process-response-end-of-body explains this quite well and this next text doesn't do it justice.

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

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