Recently at Drawbotics, we started switching our tech stack from REST to GraphQL powered by Apollo Client. Since then, our data management has been greatly simplified and the friction between back-end and front-end is minimal.

One of the things we were using previously to fetch the data and interact with the API were Redux actions combined with epics from Redux Observable. In fact, we liked the epics concept so much that we started putting a lot of logic inside those epics. Not only logic that would interact with a server, but also things that should happen in a sequential order starting from an action or to notify parts of the system in parallel.

As such, we had a lot of epics starting workflows based on actions dispatched to get or to modify some data. However, with the migration to Apollo Client, those queries and mutations were being run inside the context of a component so the epics were unaware of them happening.

For example, every time an user performs a purchase in our platform and credits are deducted, we want to display an alert. Before, we had an epic listening to every action of the type CREDITS_SPENT triggering the correct workflow of dispatching an alert and deducting the credits from the user. Essentially, that flow was encapsulated in the action. But with Apollo Client, and more specifically React Apollo, we had to: call the mutation, then display the alert, and then dispatch another action to deduct the credits, and every component that was “spending credits” needed to replicate this. And if we take into account errors, the same happens.

That’s why we created react-apollo-redux. With this small library, every mutation with a name will dispatch a corresponding Redux action.

React Apollo Redux Logo

React Apollo Redux

With this library, every mutation you call will dispatch a Redux action in a totally transparent way for you. The surface of the API is really small, in fact, it is exactly the same as react-apollo so if you know how to use the latest you’ll know how to use React Apollo Redux.

The behavior is of the library is:

When you call a mutation with a name, an action with the following type is also dispatched: @@MUTATION/MUTATION_NAME_IN_UPPERCASE . The payload of the action is the arguments used to call the mutation. When the mutation is resolved with success, an action with the type @@MUTATION/MUTATION_NAME_SUCCESS will be dispatched and the payload contains the data used to call the mutation and the data received from the server in response. If the mutation results in an error, an action with the type @@MUTATION/MUTATION_NAME_FAIL will be dispatched. The payload will contain the data used to call the mutation and a meta property containing the error.

Example

And… here’s a small example project you can use to play with and see if the library suits your needs.

And of course, we will gladly accept contributions and new ideas.