I'm excited to officially announce the initial release of a new library I wrote called saga-query.
For the past month, most of my free time has been dedicated to building a new
way to manage data fetching using
redux-saga, primarily for
react apps. My goal for this library is to create a koa-like middleware system
for interacting with APIs using
There are a lot of common processes to fetching API data:
- Preparing the HTTP request
- Setting loading states
- Making the HTTP request
- Processing the results
- Storing the results
On top of those common ETL processes, there's also UX-specific functionality baked into it:
- Optimistic updates
- Offline support
- Error handling
I love koa, it's a simple web server written in node.js
that creates a robust middleware system that allows end-developers to manage API
requests and responses. I thought to myself: what if we did that same thing on
the front-end? What if we could create a middleware system using
that handles all the ETL logic of interacting with an API? That idea culminated
This library was ultimately inspired by react-query, redux-toolkit, and koajs.
Those libraries offer a ton of functionality for data fetching and caching.
redux maintainers have done a great job moving the state management
ecosystem forward by creating common abstractions people can use to reduce
boilerplate. However, there are no common abstractions being built for people
redux-saga which is my library of choice for medium to large sized
redux-toolkit heavily prefers
redux-thunk and has little interest
in supporting paradigms that revolve around sagas.
react-query has made the distinction clear between UI state and API data for
state management. Data, they argue, should be automatically cached and not
something the end-developer needs to think about. I love this idea because
caching API data is a huge part of constructing a front-end application.
However, for medium to large sized projects, I've inevitably needed to control
the async flow control as well as the caching logic for my API data. It's not
uncommon to performance tune my selectors, build special indexes to make queries
faster, and to leverage memoization with
reselect to squeeze performance out
of my data caching layer. I'm also not a fan of every piece of business logic
living inside of the view layer,
react. I think with
consuming to entire stack and I find that to be less than idea. I want my
side-effects to be treated as data and separated from my view layer. For these
reasons and more,
react-query is not something I would reach for unless it was
a small application.
To learn more about why I prefer
If you're like me, someone who prefers treating side-effects as data and wants full control over the data synchronization of your application, I recommend giving saga-query a try. This library, coupled with robodux will not only reduce boilerplate, but give you total control over fetching and caching logic using a koa-style middleware.
Visit the Github repo to learn more.