FWIW, you should also switch to using our official Redux Toolkit package [0] if you haven't already. RTK is our recommended approach to writing Redux logic. It includes a number of utilities that build in our best practices, prevent common mistakes, and simplify most Redux use cases.

Related to that, we've rewritten the Redux docs tutorials to teach use of Redux Toolkit and the React-Redux hooks API as the default, as well as using simpler patterns like structuring Redux logic as single-file "slices". See the new "Redux Essentials" [1] and "Redux Fundamentals" tutorials [2] for examples.

[0] https://redux-toolkit.js.org

[1] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[2] https://redux.js.org/tutorials/fundamentals/part-1-overview

You should switch .. we've re-written .. does the re in react stand for rewrite?

Not presented seriously, tongue in cheek only, but it's a serious concern!

While I totally agree that hooks reduce code size a lot, and have used them to great effect, the feeling that hooks are weird has not faded.

I know exactly what they do, and usually help co-workers with weird edge cases, but I still have a feeling that we could do better.

Anyway wanted to mention that since redux is so ridiculously tiny, its simple to actually nest it. Components can have local state, and only transmit global state on business related changes.

Now with hooks and useState thats a bit more ergonomic, but you could do that way before hooks were introduced.

I know what you mean to some extent. I feel hooks are very powerful but I think they are only a refinement on a fundamental problem which is handling reactivity in your view layer is always going to have issues. I would guess you kind of hit on something similar by having your localized Redux states.

Something I'm looking at right now is Effector. It encourages many smaller stores and allows for handling of effects quite easily. The smaller individual stores avoid the performance issues that people bring up often with Redux and I feel the API is more fluent, avoiding some of those boilerplate concerns, some of which are admittedly addressed by Redux Toolkit.

I'm not sure how my time with Effector is going to play out but I suspect it is at least the right idea. I wouldn't be surprised if a similar library came out that was embraced more by the community

> For me the introduction of hooks was amazing as it's allowed us to strip most of the redux state management in favour of managing state with hooks inside of functional components. We still use redux for global application state, but there are also hooks for interacting with that redux state too.

I stopped writing React around the time Hooks came out, but I used to use a similar pattern with higher order components. In particular, I preferred HOC for forms. From what you're saying it sounds like hooks replaced a lot of that HOC functionality. Are HOC still used at all?

HOC have mostly fallen out of favour due to hooks. Typing hooks is a little easier than using HOC because you don't have to determine the type of your props which could conceivably be a combination of multiple HOC and the actual props your component expects. With hooks your props are your props which you have a simple interface for and then the hooks can be typed based on their parameters and what they return like any other function.

HOC are the more lispy/dynamic way of doing it I would say and in Clojurescript using Reagent it has always been common to use that general pattern I feel.