React-redux: Is hooks an antipattern within the context of Redux?

[GGAlanSmithee]

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!

[timdorr]

The easiest thing you could do, if coupling is such a concern, is to just break out the Redux hooks to a separate component that wraps a component with the non-Redux stuff in it.

Otherwise, you can just stick with connect. There's no plans to ever get rid of it and it still works perfectly fine.

[GGAlanSmithee]

@timdorr

Thanks for your answer.

The easiest thing you could do, if coupling is such a concern, is to just break out the Redux hooks to a separate component that wraps a component with the non-Redux stuff in it.

Yeah, as I outlined I already reached this conclusion;

Also, there is nothing stopping you from creating a hooks based HoC (something like #1065 (which i really like BTW)), but since there is already connect, what's the point?

but I was hoping to have a discussion regarding this on a theoretical level since I have a few reservations regarding the recent adoptation of hooks as a de-facto replacement of connect, even though it's not.

If you think such a discussion is valuable, please re-open this issue, othervise thanks for your time and interest.

[timdorr]

We've already had these discussions. Check out #1252 and #1179.

[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?

[timdorr]

Not really. You don't have to use hooks if you don't want. That choice is up to you.

[GGAlanSmithee]

Alright. Thanks for the conversation :+1:

[markerikson]

I specifically addressed this kind of question in my blog post Thoughts on React Hooks, Redux, and Separation of Concerns, and again in my recent React Boston 2019 talk on Hooks, HOCs, and Tradeoffs (which is based on the blog post). Please read through those.

[GGAlanSmithee]

@markerikson thanks for the additional info. I will read and watch those!

[GGAlanSmithee]

@markerikson I've read your first blogpost and it echoes my thoughts almost to the letter! Good write-up, and I guess it boils down to making a conscious tradeoff, just as you and @timdorr pointed out.

Very weird I did not find it while googling though, I searched quite a lot. If it isn't already, I think you should link to it from the docs.

The only thing I disagree with you about is that I (possibly misinterpreted you) took it that you somehow equated usage of react hooks (which I in general promote over the old state) to usage of react-redux hooks which I think is quite different.

[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]

Alright, fair enough, I see your point. PR will follow (tomorrow probably)

[GGAlanSmithee]

PR is here: #1405

Thanks for the conversation. I feel that I acheived both my objections as I now have a better understanding of the trade offs when using hooks and that the docs might reflect these concerns in some manner. Thanks for taking your time.