Re: [whatwg/fetch] Editorial: Add prose about constructing a request (PR #1585)

@noamr commented on this pull request.



> @@ -8385,6 +8388,69 @@ correctly. This section aims to give some advice.
 
 <p class=XXX>This is a work in progress.
 
+<h3 id=fetch-elsewhere-request>Populating a request</h3>
+
+<p>The first step in <a for=/>fetching</a> is to create a <a for=/>request</a>, and populate its
+multiple associated parameters.
+
+<p>Start by setting the <a for=/>request</a>'s <a for=request>URL</a> and <a for=request>method</a>,
+as defined by HTTP. If your `<code>POST</code>` or `<code>PUT</code>` <a for=/>request</a> needs a
+body, you can assign or stream it to <a for=/>request</a>'s <a for=request>body</a>. [[HTTP]]
+
+<p>Set your <a for=/>request</a>'s <a for=request>client</a> to the
+<a>environment settings object</a> you're operating in. Web-exposed APIs usually operate on
+<a>platform objects</a> (e.g. a <cite>Web IDL</cite> based API), which have a
+<a>relevant settings object</a>. For example, a <a for=/>request</a> associated with a DOM
+<a for=/>element</a> would set the <a for=/>request</a>'s <a for=request>client</a> to the element's
+<a>node document</a>'s <a>relevant settings object</a>. [[WEBIDL]]

Totally agree that documentation for this is lacking. Let's fix it step by step.
btw client is not mandatory. Instead of a client you can populate the request's origin and policy container, and respond to callbacks on a parallel queue (some anonymous new thread). For some of these features maybe that's the right approach and we should address this in this documentation.

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

Message ID: <whatwg/fetch/pull/1585/review/1237857251@github.com>