Why React projects still use Redux

Hi :) Since I got quoted here, I'd like to add some additional, er, "context" to the discussion :)

The big thing here is that Context and Redux are very different tools that solve different problems, with some overlap.

Context is not a "state management" tool. Its only purpose is to make a single value accessible to a nested tree of React components. It's up to you to decide what that value is, and how it's created. Typically, that's done using data from React component state, ie, useState and useReducer. So, you're actually doing all the "state management" yourself - Context just gives you a way to pass it down the tree.

Redux is a library and a pattern for separating your state update logic from the rest of your app, and making it easy to trace when/where/why/how your state has changed. It also gives your whole app the ability to access any piece of state in any component.

So, yes, you can use both of them to pass data down, but they're not the same thing.

For more details, see my posts Redux - Not Dead Yet! and React, Redux, and Context Behavior

Many React devs I've met would choose Context API as the default way to manage global state. Little did they know is that without setting Context API properly, it could affect the entire application's performance.

I came across a problem where Context API would re-render every child components that it wrapped. Even memoizing the child components would still cause them to re-render. This was a big no-no for our application since it is data-heavy and will keep on growing in the future.

With Redux, it allows my team and I to debug the application easily, separate the UI layer away from the data, and be able to understand what is going with the application at all times. It is the tooling and mindset of Redux that many developers do not understand why it is such a great library. They focus too much on the boilerplate code, but in reality, it's that boilerplate code that makes maintaining the application a breeze.

Sure, not everyone needs Redux for a blog page. But when you are dealing with an application that will grow and be used by many users, you need a convention defined for you and your team to follow. When you can manage and understand the state, the actions and the UI separately in your application, only then will you appreciate Redux's beauty.

I think it comes down to size of the application I've mentioned this on another thread/post before. Your post even touches on it to some extent but if you need a highly testable code base using state/Context can make it much harder. This is because you have to essentially test the component and the state at the same time. With redux you can do these two things mostly independently (you could argue that you still need tests on how your component reacts to certain state updates and so forth).

I also feel like redux 'handles' global state in a much more maintable way for larger applications. However this is pretty much entirely a preference I don't think it's impossible to use Context API/state I think you might just have to be a bit more delligent with how you design your application.

Prior to my most recent project I was using a mix of the Context API and normal react state. However I ran into the problems of testing that I mentioned above. However that's just my two cents I'd be curious to see how others feel!

TL;DR: I feel there is a place for both it depends on the size and testing requirements of a project

I did try both and as a beginner I prefer to go with Context API because it is so easy to get started with and there is no external package to install but after reading this post I understand why Redux might be the best choice for bigger project.
I'm now considering diving in Redux deeper to get more job opportunities later!

After 3 years redux coding, I turn to usie only useReducer + props without Context, that is the most simple solution. If I faced with complex problem, then change useReducer with useSagaReducer, without use any global state.

// simple combine reducer
export const combineReducers = reducers => (state, action) => 
  Object.entries(reducers).reduce(
    ( prevState, [key, reducer]) => {
        const subState = reducer(prevState[key], action);
        return prevState[key] === subState 
          ? prevState 
          : {...prevState, [key]:subState}
        ;
      } 
    , state
  );

so i think good to know about redux, redux-saga and choose lightest state management for your app - depend complexity.

As of 2020 I keep reading everywhere that Redux should be used anymore, but I fail to find what to replace it with. The closest I found was someone who reimplemented Redux with useContext and useReducer, but to me it just feels like a doing a new worse Redux? (No proper logging, time travel, observables...)

Even Dan Abramov says he hates Redux but never suggests a proper way to replace it... Maybe it's because the global store is now considered a bad thing?

Great article, some fantastic points.

I've seen (in another article) coding using Redux and code using Context side by side, and I noticed how similar they actually were - the version using Context also used immutability, reducers, actions etcetera ... the amount of boilerplate saved was minor. Coupled with the fact that, as your application gets bigger, you probably want Redux anyway, I wonder why then not choose Redux right away.

On thing that make Redux complex to work with is managing and manipulating state in an immutable way, which gets complex fast. But the funny thing is that you have to do it anyway, also with Context and with useReducer. The code to manage state immutably can get hairy fast but there are tools/libraries to make this easier.

(one complexity that I feel Redux does have is in its numerous "side effect" management libraries such as Thunks and Sagas, this is adding to the learning curve)

But one thing is absolutely true, you're right that you highlighted this: don't push state into Redux which you can just as well make component-local! I think that's where the biggest pitfalls are.

I can imagine the difficulty and frustration of understanding redux for beginners, especially if they don't have CS background to back up with many concepts (software architecture, best practice, data flow...). However you're very right on saying that people should consider it, as there is 50% chance that they will meet this at the job. Many apps aren't built today and they have grown big, and it costs the company a lot of money to rewrite or convert it to newer version, not to mention, from a business perspective there is no incentive to do so if the purpose is just to make it easier to developers!

This is the same as Svelte vs. React, no matter how amazing I personally think Svelte is, the job perspective is much lower than React at the moment. So I would learn React first, try to get a job, and have fun with Svelte in my spare time. Until I become a senior who gets to decide what to use, I guess have NO SAY on what to use at all. I just have to follow whatever they prefer, right? :)

Context API shouldn't be considered as a replacement for Redux. It's an alternative for classic callbacks to parent at most. It's not a state manager. If some dude says that Context will replace Redux, he's living in a fantasy. I can bearly see how to compare those two

Context (or some small library based on it like Constate), Zustand, or other solutions (or combinations thereof), and now definitely keeping an eye on Recoil.

It's also worth noting that RXDB (albeit with a lot of dependency bloat), can handle not only persistence and sync, but all of your app's state management (even if its creator said it's not a replacement for Redux in an issue comment a long time ago), if you're smart about your use of storage and in-memory together. There same is true of Firebase, AppSync, Apollo, etc.

While I've avoided Redux in my own projects for over a year now, and would personally reach for easy-peasy if I did feel like I needed Redux (I never want to look at Redux boilerplate PLUS Saga boilerplate again, just to do async at that), it's still important to know if you're looking for work (there's a good chance it'll be your employer's state management of choice).

And despite my gripes about it, Redux still does it's job and does it well (except async, that's ridiculous) in an incredibly small amount of code - it may seem like bloat compared to just context or smaller libraries mostly based on it, but it's really very small for what it does and the extensibility it offers (the boilerplate, on the other hand, definitely adds up).