global default options and handlers #22
Description
Activity
Sounds good, but don't believe we can get 500b, haha
Reacted by Farzad YousefzadehWell, 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.Reacted by Charlike Mike Reagent and Balázs ÉdesI'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.
@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. :)
Yea, that's the exact comment developit/mitt#11 (comment), and i'm totally agree with him.
Reacted by Farzad YousefzadehThis 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 😀
Reacted by Charlike Mike Reagent, Tucker Whitehouse, Paul Martin and JReacted by Farzad Yousefzadeh@developit You mean like an IIFE that wraps the native or unfetch altogether?
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!! };
Yeah, good pattern, agreed.
Reacted by Charlike Mike ReagentAbsolutely agree to be separate kinda nanolib. Hm, let's coin nano frameworks? haha
Unlibs
Reacted by Charlike Mike Reagent, Simon Buerger, Jad Joubran, Max Milton, Jonas Theodor and J@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?
Reacted by Charlike Mike Reagent@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, ...
Exactly! And the wrapper will work regardless of whether unfetch or native fetch gets used.
Reacted by Charlike Mike ReagentYup so much like a higher order API. Would love to contribute to the wrapper.
Reacted by Charlike Mike Reagent and Jason MillerExactly, that's the cool of micro things. : )
Reacted by Farzad Yousefzadeh and Jason MillerPrior art:
https://github.com/RickWong/fetch-plusI've written this in one of my projects sometime ago. fetch-plus seems a lot nicer though.
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.
Heh - I think that's why we haven't closed it. Need to find a good home for these things, maybe in the wiki.
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.