> Hooks addressed class component pain but introduced new kinds of complexity: dependency arrays, stale closures, and misused effects. Even React’s own docs emphasize restraint: “You Might Not Need an Effect”. Server Components improve time-to-first-byte, but add architectural complexity and new failure modes.

There are a lot of valid criticisms of React, but I don't think this is one of them. These problems are not really new with hooks. They're actually problems which existed in some form in the class component API. Taking them one at a time:

Dependency arrays: I cannot count the number of bugs I encountered which were due to a lifecycle containing some code which was supposed to be called when certain props or bits of state changed, but completely forgot to check one of them.

Stale closures: the second argument to setState allowed this exact bug. Also, people would bind methods in incorrect spots (such as in lifecycle methods) which has the same result.

Misused effects: at varying point, class components had access to the class constructor and the lifecycle methods componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentWillUpdate, componentDidUpdate, componentWillUnmount (this is from memory and is definitely only partially complete). Misuse of these was incredibly common. An article like "You Might Not Need an Effect" but titled "You Might Not Need Lifecycle Methods" or "You Might Not Need the Second Parameter to setState" would have been very helpful in the past.

Hooks reduced the number of opportunities for making mistakes, make enumerating those opportunities easier, and, critically, made them easier to detect and warn users about.

▲

fastball 14 hours ago | parent | next [-]

The dependency array thing is really easy if you use eslint with the react rules of hooks.

▲

Etheryte 6 hours ago | parent [-]

I'd say that most of the time, that's the wrong thing to do. For the vast majority of effects, you don't actually want to call it for every variable that's referenced in it. A good example is literal arrays, functions, and so on, if you have a prop that's an inline function definition, you'll be calling the effect on every render because the reference is new. You could work around this by memoing every inline function definition, but at that point, what are we even talking about. Hooks are a leaky abstraction, and while they do solve many real problems, they come with a lot of heavy baggage once you get into the thick of it.

	▲	rimunroe 5 hours ago \| parent [-]
		> You could work around this by memoing every inline function definition, but at that point, what are we even talking about. This is a normal part of optimizing React components and the exact reason for the React compiler’s existence.

▲

ibash 12 hours ago | parent | prev | next [-]

Disagree. Hooks took one problem and reshaped it, they didn’t actually solve the problem.

With hooks you still need to think about lifecycle, side effects, and state, but the syntax changes.

The real solution is overall application design and thinking through architecture, but unfortunately that’s higher effort than “just use hooks bro”.

	▲	rimunroe 2 hours ago \| parent \| next [-]
		I'm not sure why you think you're disagreeing as my entire comment was explicitly about how the issues people blame on hooks existed before, but that hooks changed how they were presented/encountered. I literally began it with: "These problems are not really new with hooks. They're actually problems which existed in some form in the class component API." As the rest of my comment points out, the thing hooks did was make these issues more tractable by reducing the places it was possible to make them. Instead of worrying about which logic is needed between the constructor and over eight lifecycle methods (the number of these was reduced over time of course) for your components, you just have to ask "what does this effect depend on?", "What should it do?", and "how should it clean up after itself?". This reduces the number of places it's possible for bugs to appear but you can still make them. I believe people blame things on hooks because it forces them to confront those (often extremely subtle and hard to catch until it's too late) bugs earlier by putting them front and center, especially with a lint rule. This is good. In addition to all that, we also got two major other advantages: sharing of logic/composability and making code using hooks much more minifiable than class components (unlike functions, object properties can't be mangled/shortened by minifiers). Plus we get a vastly improved DX because of fast refresh, which is an excellent bonus.
	▲	scary-size 10 hours ago \| parent \| prev \| next [-]
		Agreed. Thinking about lifecycle, side effects and state doesn’t just go away. It’s inherent to the system you are building. Hooks is a way to address that, class lifecycle methods are another. None of these tools will magically let you ignore proper design.
	▲	likium 10 hours ago \| parent \| prev [-]
		Agreed but hooks did solve composability. It’s easier to implement very complex handling, like drag and drop interactions.

▲

typpilol 20 hours ago | parent | prev [-]

Prop testing with fast-check helps alot I've found for when little things change