You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From the whatwg spec we can readLet requestObject be the result of invoking the initial value of Request as constructor with input and init as arguments.
This makes it seem like the two following are exactly equivalent, no matter what input and init are:
fetch(input,init)fetch(newRequest(input,init))
This is mostly true, with the exception of init.dispatcher (I know, not defined by the spec):
I believe it would make more sense to be able to attach a dispatcher directly to the request object so that the behavior defined by the spec also applies to the custom(s) options added by undici.
The implementation should look like...
Similar to the body Request attribute, dispatcher would be set as an attribute of the request that can be overridden using init.
I have also considered...
Status quo implies that if we are only working with Request object as input, we still need to carry over the init for the sole purpose of being able to pass a custom dispatcher to undici.
Additional context
I created a bunch of utilities to work with fetch(). Being able to work with a single value makes a lot of things simpler. Consider for example the following wrapper:
constlogWrap=fetch=>async(input,init)=>{constrequest=newRequest(input,init)// Should be fine per Whatwg specconsole.log(request.method,request.uri)constresponse=awaitfetch(request)console.log(response.status)returnresponse}
Being able to use new Request to be able to compute the merge of input and init is super useful. This causes however an issue when working with undici because of the additionnal dispatcher option.
This would solve...
From the whatwg spec we can read
Let requestObject be the result of invoking the initial value of Request as constructor with input and init as arguments.
This makes it seem like the two following are exactly equivalent, no matter what
input
andinit
are:This is mostly true, with the exception of
init.dispatcher
(I know, not defined by the spec):undici/lib/web/fetch/index.js
Line 242 in 7623f10
I believe it would make more sense to be able to attach a dispatcher directly to the request object so that the behavior defined by the spec also applies to the custom(s) options added by
undici
.The implementation should look like...
Similar to the
body
Request attribute,dispatcher
would be set as an attribute of the request that can be overridden usinginit
.I have also considered...
Status quo implies that if we are only working with Request object as
input
, we still need to carry over theinit
for the sole purpose of being able to pass a customdispatcher
to undici.Additional context
I created a bunch of utilities to work with
fetch()
. Being able to work with a single value makes a lot of things simpler. Consider for example the following wrapper:Being able to use
new Request
to be able to compute the merge ofinput
andinit
is super useful. This causes however an issue when working withundici
because of the additionnaldispatcher
option.Fixing this requires to do the following:
This implementation is not agnostic of the actual
fetch
implementation used under the hood, which breaks separation of concerns.The text was updated successfully, but these errors were encountered: