That was my initial reaction when I saw Recoil for the first time. I had already experimented with so many different solutions for the same problem that I was feeling the infamous javascript fatigue. And there was one in particular that occupied most of my time, Redux. It came out in 2015 and gained a ton of popularity soon thereafter, so it’s a definite go-to for developers. The problem is, it’s also arguably one of the most complex.

So I was a little doubtful going into Recoil. After all, if there were a simpler solution, wouldn’t someone have come up with it by now? Maybe the steep learning curve you get with Redux is the price you have to pay for a solid app. I put my hesitations aside and dove into Recoil to see how it compared with the Goliath. Let me tell you what I found out, show you an example, and then you can decide if Recoil is right for your needs.

Almost immediately I realized that Recoil was nothing like Redux. It had a simple API that felt very familiar after working with React hooks. That enabled the team to wrap our heads around how it works really quickly. And size was not an issue. Our project had a huge codebase. The monorepo had almost 100 frontend projects where Recoil was the only state management library. But even at that size with use cases that were quite complex, our team was able to get up to speed with Recoil in just a few days.

What makes Recoil so much easier to grasp? A big part is how the two differ in updating state. Compared to Redux, Recoil does not have a similar centralized state for the whole app. Instead it has two main concepts: Atoms and Selectors. Atoms are where the actual values are stored and selectors are for derived state and async logic. While having a simple structure, you can still keep most of the great functionality of Redux — like atomic state updates with easy debugging and time traveling to previous states via Recoil snapshots.

So that all sounds great, right? You probably want to immediately switch all your projects to Recoil. Before you do that, read on. We’re going to build a small app that shows a use case where Recoil truly shines. And then we’ll explain why Recoil may not be the best option for your project.

We will be building a simple editor app with the following features:

Each square has its own state that can be edited from different parts of our component tree, both from the sidebar and by interacting with the element on the whiteboard. You can find the full source code in GitHub if you want to test it locally. You can also try out the full app.

The post Is Recoil what will kill Redux? appeared first on Reaktor.