| I've more or less driven frontend development with React at several companies over the last 4 years. While some of the complaints are exaggerated I don't think the overarching premise should be dismissed as "a meme." > No idea what this promise chaining thing is that you're talking about. If you have any asynchronous things going on in `useEffect`, you'll have to do something similar to that `await(0)` song and dance in tests. This specifically affects tests if you do things like update the UI by toggling loading spinners on await. > Redux s/Redux/higher order components. One of the motivations for hooks was that as a mechanism for logic composition, HOCs just felt awful to use. (So did render props, which everyone suddenly used for everything in a brief moment of collective insanity.) > Only a superficial understanding of React I think there's something in this. The fact is that good or bad, 1) hooks aren't intuitive, 2) hooks have basically doubled React's API surface area. Previously, React was so simple that a backend engineer could pick it up and get productive with it in half a week. That's much less the case these days. I've been onboarding devs to React for years, and these days there's a lot more "yeah, that's magic, you don't need to know how that works for now." |
You should have a core (pure) functional component, that doesn't perform network requests, and an outer component for side effects.
Your testing for the inner component becomes trivial: Do the correct props product the correct HTML? Fairly trivial to validate. Use Enzyme, react-testing-library, etc.
The outer component, which contains side effects, can be covered through an end-to-end testing tool like Cypress.