Async defer about wretch HOT 2 CLOSED

Aha I see, I was unsure what is called when. It's much clearer now. Thank you for the explanation!

from wretch.

Hi @edongashi,

Is defer in principle a "managed" (wretcher instead of fetchlike) version of middlewares? It feels much easier to configure the wretcher instead of dotting into the options of middlewares.

defer and middlewares share some similarities, but as you noted the key difference is that defer is synchronous and simpler.

A middleware is more powerful in the sense that it has full power over the request and the response, whereas defer can only configure the Wretcher object but it is unable to inspect the response body (for instance).

Can defer be async?

Well it would be nice indeed, but I'm afraid it's impossible (and a crucial difference between middlewares and defer).

defer is called just before performing the fetch request, when calling the http verb method in the chain:

wretch('...')
   .get() // <- defer is called here implicitly
   .json()

Here are the relevant lines in the source code:

private method(method, options = {}, body = null) {
  /* … */
  baseWretcher = baseWretcher.options({ ...options, method })
  // If _deferredChain was be a chain of Promises, 
  // deferredWretcher would have to wait for their completion and be a Promise itself.
  const deferredWretcher = baseWretcher._deferredChain.reduce((acc: Wretcher, curr) => curr(acc, acc._url, acc._options), baseWretcher)
  return resolver(deferredWretcher)
}

The key point is that if defer accepted async functions, it would mean that method() would
return a Promise<...>.

And this piece of code:

wretch('...')
  .get()
  .json()

Would turn into:

wretch('...')
  .get()
  .then(w => w.json())

Which defeats the purpose of this lib, since it breaks the fluid api.

from wretch.