Redux vs. Recoil

Did you ever think why Facebook chose the name "Recoil" for their new state management library?

Well, it's just my assumption, but I think that the primary purpose of Recoil is to cause people to recoil from Redux.

Seriously now, there are a bunch of differences between Recoil and Redux. I am not going to cover them all in this post.

One main difference is the way we manage the global state object.

In Redux, we have one big object called "store."
When we want to change our store, we must return a new object (we can't just modify the previous one).

On the contrary, Recoil doesn't have one state object. Instead, our state is split into tiny particles called "atoms." Each atom is a small object containing only part of the state.

In my opinion, the transition from the big scary global store to the tiny atoms is fantastic.

First of all, why do I need to modify a vast object when I want to make only a tiny change in my state? That doesn't make sense.

Second and most importantly, our code is more maintainable when splitting our state into atoms. It's easy to get around and find stuff when we have a sharp separation of concerns.

I mean, that is what React is all about—splitting our app into small maintainable components.

While writing this post, I was thinking - when we change our codebase (in Github, for example), we keep track of changes in the "Redux way."

Every time we commit changes to the current branch we are working on, a new modification hash is generated for us. Very similar to the way Redux keeps track of the global store.

The whole world is going towards a component-driven development architecture. Micro-services on the backend and React on the frontend, and I'm asking myself why we still keep track of changes the old way?

Wouldn't it be more innovative to track changes on each component independently and decoupled from the rest of the source code? Like in Recoil, we modify each atom regardless of the rest of the global state.

The good news is that there's already a tool tailored to build your application the component-driven way. Its name is Bit. It lets you keep track of each component individually and handles all of its dependencies for you.

Imagine writing a component once and using it in ten (or more) applications. Updating your component with a new version will cause those applications to update with a new version of that component.

• For more posts like this follow me on LinkedIn

• I work as frontend & content developer for Bit - a toolchain for component-driven development (Forget monolithic apps and distribute to component-driven software).