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