Hacker News Reader

Comment by rimunroe | Hacker News Reader

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

View on HN

If this was the case, why do we need to define the dependency list to begin with? If this was both the mainline right thing to do and the compiler can do it, why are we doing it manually? In that case we could just as well omit it by default and only have users define it when they want something different. The answer, in my opinion, is that it's just a patch over what's a leaky abstraction and the added overhead costs more than the benefit in the end.

> In that case we could just as well omit it by default and only have users define it when they want something different.

I believe the official recommendation since hooks were announced is to omit the array unless you need it. It makes things much easier to reason about, and many effects can run on each render just fine. It's mostly[0] a performance optimization. Oftentimes you'll want to make an additional comparison between previous and current props to decide if you actually want to do something anyway.

[0] Possibly entirely. Remember that useEffect's goal is to synchronize with an outside system. Additionally, while I can't find references for a similar thing in the docs for useEffect, for useCallback and useMemo the dependency array is explicitly not supposed to give any semantic guarantees about when the value will be re-memoized. React is free to "forget" values if it wants and re-memoize when needed.

For one, running an effect on every render and running it whenever referenced variables change are two very different behaviors and not universally interchangeable. For two, this is exactly what I mean with leaky abstractions. The fact that you even have to think about this at all is a strong design smell. Vue and co do not have this limitation because they approach reactivity from a fundamentally different angle. They come with their own bag of problems, but I would argue that their smells are considerably smaller than what hooks bring to the table.

> For one, running an effect on every render and running it whenever referenced variables change are two very different behaviors and not universally interchangeable.

Yes, of course. That's why it's recommended as a first step and not as something to do all the time (though you often can if you use something like usePrevious).

> For two, this is exactly what I mean with leaky abstractions. Vue and co do not have this limitation because they approach reactivity from a fundamentally different angle. They come with their own bag of problems, but I would argue that their smells are considerably smaller than what hooks bring to the table.

I'm sure it's possible to do it better, but I'm discussing this in the context of hooks versus the class component APIs they replace.

I'm not very familiar with signals beyond what I've read about them in the past. What I've read about them sound exactly like Knockout observables[0]/computed observables[1], which I'm extremely happy to have left in the past. I assume frameworks using signals must use something to scope subscriptions or enforce update directionality?

Do signals provide a solution to knowing when to run an effect to e.g. establish or close a network connection?

[0] https://knockoutjs.com/documentation/observables.html

[1] https://knockoutjs.com/documentation/computedObservables.htm...

Reply on news.ycombinator.com