For most products, you didn't need anything besides React in the first place. It's really only useful when you have a single blob of state which is displayed/sliced/etc. in different ways across a large number of views. But for the most part, many apps are largely read-only (you can use `Context`s to push data down your render tree), where mutations happen close to where the data is loaded, meaning the benefits of redux are lost.

The big pain point of Redux (IMO) is that you do you data fetching separately from managing the data in your data store. It means that you need to add this glue layer between the data that comes back from your API and the redux store—you need to re-model everything. Every time you get new data, you need to go out of your way to remember to update everything that could be affected by that data.

GraphQL (I'm fond of Apollo) gets this more right. You can still use REST APIs with GQL (usually not by default, but it's possible). What this means is that you model your data in the way that the API expresses it. Your back-end folks aren't going to be lost when they read your code, because it matches the shape of the data they're already familiar with. The client-side cache means you don't need to manually fiddle with your store to invalidate stale data (I've yet to need to manually reach into the cache to perform updates).

That's not to say GQL is without its own issues. It is yet-another-thing, but it's one example of a solution which doesn't get quite as hairy when you've got 200+ pages in your app.

It all depends on the scope of the project, but if you use Redux as a way to keep a cache of backend data so you don't need to request everything every again in every component or pass everything down in props, then you could consider a system like graphql. One project I'm working on part time is switching from class based components + Redux to functional components + graphql and I must say I'm enjoying graphql a lot more than I was writing actions, sagas and reducers.

I don't have any recommendations for pure client side applications though, but for those you can probably get away with using contexts and hooks for quite a lot of the state management.

Most cases I've seen are just using Redux as a de facto global cache, where it can be easily replaced by a library like Apollo or SWR (https://swr.vercel.app) to just have every component make whichever requests it needs for data directly (and the library then deduplicates requests and serves data from cache).

Not the OP, but I'd suggest using what's built into React, i.e. keeping shared state in a parent component, until you hit one of the reasons the Redux docs enumerate for using it: https://redux.js.org/faq/general#when-should-i-use-redux