re: New Redux Hooks: A Before And After Comparison. Are They Better? VIEW POST

FULL DISCUSSION
 

To be honest redux hooks sucks, I think they just released for the sake of having hooks, I was afraid of people jumping on hype train and redux apparently did the same.

First when you use redux hooks with your components, it's violating the SRP principle, and your component is bound to redux, now let's say you don't want to use redux anymore, you can't.

If you say you'll just wrap the components using hooks to a separate component and pass the data down as props, then you're just implementing a connect, and hooks don't do memoization so performance also suffers.

Hooks is one of the best thing which happened to React and I love it, but the same thing is one of the worst things to happen to Redux and I hate it.

 

The Redux community expressed extremely strong interest in having us add a set of hooks APIs. I suppose you could label this "jumping on the hype train", or you could look at it as us trying to offer solutions that meet the needs of our users.

Hooks are an addition to our API. connect() isn't going away. If you want to keep using connect(), go right ahead. Hooks are an alternative. It's your choice which you use in your code.

I agree that there's a tighter coupling, but that seems to be the case with hooks in general.

 

I agree that there's a tighter coupling, but that seems to be the case with hooks in general.

I agree that the testing question becomes somewhat more difficult - you're basically having to write "integration"-ish tests now to test the component in conjunction with the Redux store state it expects. The React team seems to be encouraging more integration-style testing in general, though.

I've noticed this too Mark and I haven't seen a lot written about it. I asked a question on stackoverflow related to this tight-coupling with hooks, but haven't gotten any feedback yet:

stackoverflow.com/questions/564975...

Do you see this as something the community is still evolving best practices around? I liked the ease of testing with presentation components, but I don't see anybody advocating using hooks only in a container component and then rendering a presentation component that takes props and is more loosely-coupled (but more boilerplate). Both Kent C Dodds and Dan Abramov seem to be advising against doing that:

So it seems hooks requires more mocking of any fetch calls in custom hooks and also mandates wrapping components that use redux hooks in a provider, etc. But with the embrace of react testing library philosophy and focusing less on implementation details and more on user experience, maybe this isn't such a bad thing?

Yeah, I think the community is still trying to figure out best practices around hooks in general.

Think about it this way. React came out with mixins at the beginning. It took a couple years for the community and team to say "mixins are bad, use HOCs". It took another couple years for folks to figure out that the "render props" pattern was even possible. Hooks have only been out officially for a few months - we're going to be exploring their implications for a while.

 

Personally I can only see myself using them in my top level route handler components where I am not concerned about the tight coupling they introduce.

In fairness to Redux, this tight coupling is just a problem that hooks in general introduce.

It's just trade-offs at the end of the day.

 

First when you use redux hooks with your components, it's violating the SRP principle, and your component is bound to redux, now let's say you don't want to use redux anymore, you can't.

This is not true you still can and should have your presentation and control components separate by using a wrapper control component with hooks that passes props down to a presentatioon component that is not aware of redux. It's just that the connect HOC does this without requiring us to write the boiler plate of another control component. So yes, hooks are not a replacement for connect but they are heck a convenience feature in situations where you might need a bit of state and the component is not a re-usable presentation component such as your top level page.

 

I don't know where you got that from, like I mentioned before, if you're doing on parent level, you're doing what hoc is doing, second it's has performance impact, you can read about it in redux docs. With hoc you can use reselect and connect itself avoids re-renders, but that's not the case with hooks.

At our company after a looooot of consideration, we banned redux hooks from usage.

Except useSelector does a strict equality check by default and you can pass a shallow equality comparer function to it for well, shallow comparison just like connect. If any of these techniques result in equality, the hook does not cause a re-render. You do realise that the connect HOC itself is implemented using hooks right? You should read the source code. It's just really easy to use till you figure out hooks.

code of conduct - report abuse