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

re: 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 ...

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:


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.

Code of Conduct Report abuse