Is the goal to be 100% compatible with axios?
AjaxSolutions opened this issue · comments
As of this writing some axios features are still not supported.
Aside from uploadProgress and downloadProgress, the goal is to support most/all features. If the size increases too much, it might make sense to provide a lite version that doesn't include configuration inheritance or interceptors. This would be useful for folks who are just using Axios as a simple convenience lib for making network requests.
.interceptors for instance is missing on a redaxios instance
Potentially philosophical-ish question- if there becomes 100% parity between the two libraries, why would I ever choose to use axios over redaxios?
I doubt the end result is 100% parity, since Fetch is only just now getting progressive upload support spec'd out.
The philosophical goal of this library is not to reduce the size of axios (it's not even that large). It's make it easy to move to Fetch without requiring a refactor. For folks looking to squeeze the size of their code, redaxios still includes a bunch of architectural niceties from Axios that are often unused - moving to a small purpose-built wrapper around fetch should really be the goal.
you are jebaiting people by referring to the axios documentation. that implies this a drop in replacement
I agree, I would state in the docs that this is not a drop-in replacement library.
Nowhere in the readme do I state that redaxios is intended to be identical to Axios. That would make the module pointless.
It doesn't make sense to replicate Axios' documentation here, because redaxios is a strict subset of its functionality. A list of compatibility notes would be better, I simply haven't had the time to write it and currently would prefer to spend that time merging the open PRs that ultimately reduce those differences.
I don't think there is any readme text that would address the issue of folks believing that this is somehow a simultaneously
a byte-for-byte identical clone of axios and 80% smaller than axios. There's no magic that makes things free, everything is a tradeoff - pretty much every project I maintain can be considered to have that disclaimer.
well, then how does one understand what is and is not implemented? you only linked to the axios document, so that would make people assume everything is implemented.
even in the readme you say // use as you would normally, except that's a lie
Nowhere in the readme do I state that redaxios is intended to be identical to Axios. That would make the module pointless.
It doesn't make sense to replicate Axios' documentation here, because redaxios is a strict subset of its functionality. A list of compatibility notes would be better, I simply haven't had the time to write it and currently would prefer to spend that time merging the open PRs that ultimately reduce those differences.
I don't think there is any readme text that would address the issue of folks believing that this is somehow a simultaneously
a byte-for-byte identical clone of axios and 80% smaller than axios. There's no magic that makes things free, everything is a tradeoff - pretty much every project I maintain can be considered to have that disclaimer.
Absolutely. My comment was not intended do bash the project or something.
I did comment because in the company where I work, we choose to change axios to redaxios because of what is stated in the readme. These were the selling points for us:
- Axios has a great API [...] Redaxios provides that API in 800 bytes [...]
- [...] Redaxios exists so that you can use that same API [...]
import axios from 'redaxios';// use as you would normally
Based on those points, seems that redaxios IS a drop-in replacement.
I will prepare a PR with compatibility notes.
Anyway, thank you for your time and the library.
We are still currently using redaxios in production, but axios if we need onUploadProgress.
One part of this that is perhaps worth mentioning is that portions of the differences are just because redaxios is new, and there's still work to do.
This part of the documentation is misleading and open to interpretation. It should be made more explicit what was said above to avoid misinterpretation.
