global default options and handlers

[farskid]

Since fetch apis are used a lot in a typical web application, it would be nice to have a unfetch.defaults object that sets default parameters of all requests. A use case would be to set base URL of all requests.

unfetch.defaults.baseURL = 'my-api-endpoint'

[tunnckoCore]

Sounds good, but don't believe we can get 500b, haha

[farskid]

Well, having a useful feature to cost some bytes wouldn't harm I guess. Let's watch the package size to see if there is a chance for adding this feature.

[tunnckoCore]

I'm agree with you and was thinking the same thing when mitt came - in its case we can get few more features if we allow 20-30bytes more, but @developit is holding strongly that it should be 200b. I'm agree with him too and there was a discussion like if we allow such things we'll get to point such as "let's add more more 1-2kb" haha and was mentioned momentjs that it started like micro lib.

So yea, it is good thing to try to be strict.

[farskid]

@tunnckoCore HAHA did not know that momentjs was a micro library at the beginning. Looking forward to hear about the decision from @developit . This feature whether added or not, both seems logical to me at the moment. :)

[tunnckoCore]

Yea, that's the exact comment https://github.com/developit/mitt/pull/11#issuecomment-273132616, and i'm totally agree with him.

[developit]

This discussion makes me happy :) Let's keep this on a list of nice-to-haves that we can look to if we save bytes.

Btw - for defaults, we should make a wrapper library, that way they would work for native fetch too 😀

[farskid]

@developit You mean like an IIFE that wraps the native or unfetch altogether?

[developit]

Yup, a way to inject defaults by proxying window.fetch:

let real = window.fetch;
window.fetch = (url, options) => {
  // Apply URL and options transforms here
  return old(url, ootions)
    .then(options.after || Object);
               // ^ middleware!!
};

[farskid]

Yeah, good pattern, agreed.

[tunnckoCore]

Absolutely agree to be separate kinda nanolib. Hm, let's coin nano frameworks? haha

[developit]

Unlibs

[developit]

@tunnckoCore @farskid - what do we want to do with these types of issues/PRs? We can't merge them because of the nature of this library (it being a polyfill and thus bound by the spec it emulates), but I hate closing them when there's good discussion and tasks to be taken away. Maybe we need a repo/place where these ideas/implementations go so that we can build up a set of feature requests for wrapper libraries?

[farskid]

@developit @tunnckoCore I guess a wrapper for addon features is a nice idea. Devs can either use the super light version or pay the price of not so much light version for the extra features such as global configurations, extra handlers, ...

[developit]

Exactly! And the wrapper will work regardless of whether unfetch or native fetch gets used.

[farskid]

Yup so much like a higher order API. Would love to contribute to the wrapper.

[tunnckoCore]

Exactly, that's the cool of micro things. : )

[developit]

Prior art: https://github.com/RickWong/fetch-plus

[notpushkin]

I've written this in one of my projects sometime ago. fetch-plus seems a lot nicer though.

[developit]

@iamale totally stealing that

[MobiusHorizons]

Learned a lot just reading this thread!! There are a lot of good ideas happening here. Is there a way it can be preserved? If it were closed, it could still be linked to from a wiki or something.

[developit]

Heh - I think that's why we haven't closed it. Need to find a good home for these things, maybe in the wiki.

[notpushkin]

Another thing that I had in mind since I wrote arequests is this:

const api = Afetch({url: "https://api.github.com"});
let mdo = await api.users["mdo"].get();
let json = await mdo.json();  // or whatever you'd do with a regular Fetch object