undefined | Better HN

0 pointstimhwang215y ago0 comments

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."

0 comments

6 comments · 2 top-level

JMTQp8lwXL5y ago· 4 in thread

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

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.

schwartzworld5y ago

> You should have a core (pure) functional component, that doesn't perform network requests, and an outer component for side effects

IMO, this is the biggest thing we lost with hooks. Before there were two different types of component, and you couldn't make a pure functional component stateful or effectful without completely rewriting it.

I love hooks, but I'm constantly asking in code reviews "are you sure this is where you want this state to live?".

The other big problem with hooks is that there are no safeguards (and little documentation) about using them wrong. The post you're responding to mentions using `useEffect` to toggle a loading spinner. This might make sense if the loading spinner is outside the React component tree, but if you're using useEffect to toggle some piece of React state, yer doin it wrong. Once you start slipping these kinds of hacks into a codebase, it's a slippery slope.

timhwang21OP5y ago

This is true as long as you're able to strictly enforce the container-presenter pattern, which is increasingly harder to do as an application grows in complexity.

JMTQp8lwXL5y ago

If you're using a Design System (a base level of common UI components), the separation helps enforce the design system acting as the "presenter".

BreakfastB0b5y ago

  You should have a core (pure) functional component, that doesn't perform network requests, and an outer component for side effects.

Except when you go to use that container component inside another component. Then you’re back to the same problem. Unless you’re advocating for a single container component at the top level in which case we completely agree!

dragonwriter5y ago

> Previously, React was so simple that a backend engineer could pick it up and get productive with it in half a week.

With hooks, I've literally seen almost completely novice programmers (e.g., people who’d hacked out some powershell while working desktop support previously) pick up React and be productive in a month or so, while also learning JS and Python and SQL and backend development from scratch in parallel; if backend “engineers” can't do it in half a week or so, they’re hacks.

j / k navigate · click thread line to collapse