Redux vs. Recoil

Which is better?

You’ve likely heard of Redux. It’s a popular state management tool for JavaScript apps, including React sites. Its website says it’s predictable, centralized, debuggable, and flexible.

And it has some competition.

I’ve been hearing more about Recoil lately. Recoil is said to be easier to work with than Redux. But each one has its pros and cons.

Let’s take a brief look at them. But first, let’s define some of their terms.

Vocabulary

In Redux, the source of truth is in one store. In order for components to access the store, they need to be wrapped in Redux’s Provider component.

You need to define:

• Actions to describe the shape of data sent to the store.
• Reducers to receive and use actions to update the store.
• Selectors to read from the store.

Understanding all these definitions takes a while.

Recoil operates differently. The state is split up into small units called atoms. In order for components to access atoms, they need to be wrapped in a RecoilRoot component.

You do not need to define:

• Functions to update atoms.
• Selectors to read from atoms.

These are built into Recoil.

Redux

Redux is the king of state management libraries. It’s been around for more than a decade. According to NPM Trends, Redux has more than twice as many downloads as Recoil:

But is a king always the best ruler?

Pros:

• Redux is established.

Because it’s older and more popular than Recoil, Redux has a ton of documentation. Look at the size of the sidebar on its documentation page. It’s a lot longer than Recoil’s:

Of course, quantity does not always guarantee quality. But hundreds of companies use Redux. It’s more reliable and less experimental than Recoil.

• Redux is more general.

Redux is for JavaScript apps, not just React ones. If you want it to work specifically with React, you can use React Redux, its companion library.

But Recoil was built as a state management library solely for React. It removes some inefficiencies that Redux has. For example, only components that read from an atom will re-render when the data in an atom changes. I’ll explain why Redux can be slower at that.

Cons

• Redux requires more boilerplate code to use.

Remember Redux before Redux Toolkit? You had to set up constants so you could use them in your action creators so you could use them in your reducers… and so on.

Now, Redux has configureStore and createSlice methods that make life a lot easier. For example, you can define a slice with a name, state, and reducer function like this:

const employeeSlice = createSlice({
  name: "employee",
  initialState: {
    title: "Manager",
  }
  reducers: {
    setTitle: (state, action) => {
      state.title = action.payload;
    }
  }
});

But you’re still responsible for making selectors and using the useDispatch hook to update the store.

Recoil is more elegant. For example, you can define an atom like this:

const employeeState = atom({
  key: "employeeState",
  default: {
    title: "Manager",
  },
});

Then use the useRecoilValue method to read the atom’s data:

const employee = useRecoilValue(employeeState);

And useRecoilState or useSetRecoilState to update the atom’s state:

const [employee, setEmployee] = useRecoilState(employeeState);
// or
const setEmployee = useSetRecoilState(employeeState);

This makes Recoil more intuitive than Redux.

• Redux can be slow.

Say you have an EmployeeProfile component that displays an employee’s ID and name. You have a list of EmployeeProfiles on the screen. Each one gets its data from the payroll reducer with a selector:

const selectEmployee = id => state => state.payroll.employees[id];

If you edit an employee, only the EmployeeProfile displaying that employee will re-render. But if any part of the reducer state changes, this selector will need to recalculate its return values.

Even if you use createSelector to recalculate a selector’s output only if the inputs change, Redux still has to check if the inputs changed.

This isn’t necessarily a big deal. The Redux docs say that most apps are not complex enough to slow down because of this. But it could be worth noting if you have a complicated application.

Recoil might handle these situations better.

Recoil

Recoil was created three years ago by Facebook. Some have described it as more user-friendly than Redux. It’s easy to see why: It has built-in selectors and ways to update the store. But that’s not all.

Pros:

• Recoil handles pending data.

Recoil has a Loadable object that makes it really easy to render different things depending on if an atom’s data is available.

You can use the useRecoilValueLoadable hook to read from an asynchronous selector. This hook will return a Loadable object. You can read its state property to show a loading sign if the data is loading and something else otherwise. Like in this EmployeeInfo component:

const EmployeeInfo = ({employeeID}) => {
  const employeeLoadable = useRecoilValueLoadable(selectEmployee(employeeID));
  
  if (employeeLoadable.state === 'loading') {
    return <LoadingSign />;
  }

  if (employeeLoadable.state === 'hasValue') {
    return <EmployeeProfile employee={employeeLoadable} />
  }

  return null;
}

Cons:

• Recoil is larger than Redux.

On NPM, Recoil’s unpacked size is 2.2 MB. Redux’s is 179 KB. This means Recoil is twelve times larger than Redux. Even if you used both Redux and React Redux, Recoil would still be more than four times larger.

It’s important for applications to be as small as possible. The larger an application is, the longer it takes to send it over networks, load it, and execute it.

So Recoil isn’t ideal if you want to reduce your bundle size.

• Recoil doesn’t support middleware / global states.

You can get Recoil to change many atoms at once and work with remote databases. But as this GitHub discussion demonstrates, it’s not super straightforward.

And while atoms are supposed to work with the closest RecoilRoots, it can be frustrating that they can’t really work outside components.

So Recoil might not be the best choice if you want atoms to rely on persistent stateful instances.

Conclusion

So, Redux and Recoil have their own benefits and drawbacks. While Redux is more established, it can be slow and requires a steeper learning curve to understand. Recoil is more React-specific but will increase your bundle size more.

This article only covers some basics about Redux and Recoil. If you’d like to learn more about them, this article is a great place to start.

These packages continue to grow every day. I’m excited to see what new developments they have… in store.

Haha.

Thanks for reading.