> This is the ideal use case for react context. Not really. React.Context solves the global availability bit but it does not scale with the size and complexity

> This is the ideal use case for react context. Not really. React.Context solves the global availability bit but it does not scale with the size and complexity of your data. You'll end up building a custom Redux store inside your Context anyways, except now with an uglier API and no devtools. Alternatively, you could just use a bunch of independent React Contexts, but that becomes unmanageable quickly especially if the Contexts are interdependent. > Redux doesn't address these problems specifically, but I'd be curious to understand why you think redux is of particular value for them. The action/reducer model is a very natural way of modeling it. The business logic and data fetching layer is completely disjoint from the actual data store. We can simply describe what happened -- hey, we tried to post this data, this request succeeded, but this one failed and here's the error message -- and then let the reducers decide how that updates their state, if at all. It makes it much easier to refactor code and add new features, especially when they can just hook into existing actions. Even if I didn't use Redux -- and to be honest I don't love the API sometimes -- I would follow the Redux patterns. When done well it's a really seamless way of managing data that would otherwise be a lot of ugly business logic spaghetti. > have mentored about two dozen developers on react and redux projects over the past three or so years, I've learned this lesson the hard way. If you're mentoring novice developers I don't doubt the apps they were working on didn't necessitate Redux. It's a powerful tool but it comes as a price, which is why as much as I like it I avoid recommending it to people (especially junior developers) unless they have a really good case for it.