TL;DR; we were already using fetch with some not-so-practical helpers.
I found out about **fetch** a while ago when I was looking for what to use to do HTTP requests on React apps. Coming from jQuery and Angular this was something I’ve never had to worry about because I would just use what the library/framework provided, and be happy with it.
I get really excited about anything that pushes the web further and makes it better. And particularly with **fetch**, there are many reasons to get excited about:
- A nice API. In your face XMLHttpRequest!
- Request/Response primitives
**'no-cors'**and opaque responses- Streams
- Stream readers & cloning
- Headers class
- Cache control
- No-credential
**same-origin**requests
You can read about them in depth in Jake’s post.
Adopting fetch
It is JS we are talking about, you gotta use the latest stuff, right?
Jokes aside, after trying it out for a little bit with some PoC’s, I got the perfect opportunity to use it at work. I was starting a new project and thanks to the Github’s polyfill, I could already use it safely on those browsers that don’t have support yet or will never have it. Great!
Native API cons
Now **fetch** is a native API, and thus it's not its job to provide a library-like interface, with helpers and shorthand methods. After some time of using it, I ended up with a bunch of helpers. Like these:
And this is how every request looked like:
You could say there’s nothing wrong with it, but it didn’t feel right. I didn’t want to start another project and straight up copy my **fetch-utils** file. Neither I liked having a bunch of helpers, which is not bad at all, but I knew I could do better.
So I shared my concerns with Nico and he was like “yo I got the same problems!”. After discussing for a while some ideas and wrapping our heads around, we started to write a library.
And that’s how we ended up with trae.
Cool, but…
Cool but, how does it compare to axios?
Not only a lot of people asked that but we also did it ourselves.
Being kind of the default HTTP library it surely influenced us. Going through its code helped us a lot to understand the needs and internals of an HTTP library and to improve and polish some of our own ideas. If you want to read well organized, written and documented code check it out. I must admit, I even am a secret fan of Matt.
But axios uses XHMLHttpRequest internally. If you haven’t yet, check out Jake’s post to learn more about fetch and what are the improvements over XHMLHttpRequest.
Besides that, trae, like axios, is just an HTTP library. And, I might be biased here but, I would say it’s a nice one. So If you are excited like us about fetch and want to use it, and at the same time want to have the goodies of a library, give trae try.
trae, what does it even mean?
After going from Hermes, Charon, Huginn and Muninn to famous dogs and even messenger pigeons names we settled up with something simple and even funny, trae**.** It means brings in Spanish, and we felt like for a library that's all about fetching data it was a good fit.
What’s next?
There are some to-do items on the list, but regarding the library itself we like its API and think, even though young, it’s already mature enough to say we won’t make big breaking changes to it.
That doesn’t mean aren’t going to make improvements. We are using trae on a daily basis, and are looking for new ways to make it better. I even have the, maybe not so crazy, idea of building a dev tools extension with a bunch of cool stuff on it.
We are very open about contributing, so feel free to ask anything or even submit a pull request if you find something to improve.
Conclusion
Whenever you find a way to improve your workflow take it a step further and make something out of it, whether it is a library, a small module or a tool. You will learn a ton in the process, and what’s even better you will help many other people. OSS FTW!!!