Is hooks an antipattern within the context of Redux?

Hi,

This issue is not meant to start a flamewar or to bash this wonderful library. Also, I do not intend to disrespect the contributors of it, but I am looking for some insight and for an open discussion about the usage of hooks in the context of redux.

I’m a huge proponent of hooks as a replacement of the old React class state + lifecycle methods. It’s IMO way easier to reason about the flow of data, to identify bugs and to reuse and compose state / functionality with this API.

Regarding react-redux I’ve always liked the usage of a HoC (connect) to inject state to props as it nicely decouples the implementation (redux) from the application (accessing data). Now, I understand that the hooks provided by react-redux aren’t supposed to be a replacement for connect but the usage of hooks within the context of Redux feels almost like an antipattern to me.

Hooks does (subjectively) provide a nicer API and reduces boilerplate, but it - IMO - encourages bad design decisions that leads to a more tight coupling of redux and components that reduces usability, testability and violates the SRP. Also, hooks comes with a few potential pitfalls that aren’t obvious.

The mitigating factor to the tight coupling is that there often is a de-facto coupling to redux even if there isn’t a programmatic one. Also, there is nothing stopping you from creating a hooks based HoC (something like https://github.com/reduxjs/react-redux/pull/1065 (which i really like BTW)), but since there is already connect, what’s the point?

I really want to like react-redux hooks and given the widespread adoptation of it amongst my peers I guess there’s something I’m missing. So if anyone of you would like to enlighten me and have a productive (though late) discussion regarding this it would be awesome.

Thanks for maintaining this awesome lib!

[markerikson]

I just put up the post a few weeks ago, so who knows how much SEO juice it has.

I was generally equating React-Redux hooks to React hooks in general, and especially with any custom data management hooks.

Overall, any use of a useContext() will effectively couple that component to the corresponding <Context.Provider>. That includes useSelector(), or a roll-your-own state+context combo.

Similarly, useEffect() directly pushes you towards handling data fetching inside a component, vs separating that out to another component.

So yes, I’m making the point that hooks push you towards “do it all in one place”, vs separating that into multiple components, and React-Redux hooks are a specific example of that behavior.

And yeah, feel free to file a PR that would add a link to that in the docs.

[GGAlanSmithee]

@timdorr

Thanks again.

I did read those and other issues before opening this one, but did not catch the “should we use hooks” discussion, but rahter the ones focusing on “how should we use hooks”, which is actually where my original concern comes from, that this pattern is being accepted as a must-have on face value, while I’m arguing it might actual be harmful and an architectural regression.

I understand I’m a bit late to the party and that there will be no significant changes to your API. I was hoping at most to get educated and for some clarifications in your documentation regarding when it’s appropriate to use hooks and what potential issues there might be in addition to the technical ones.

Are there any agreement with these sentiments and is there any interest for such documentation changes?