> Yes, but it will not actually matter in >99% of real world cases. And this argument is exactly what the article mentions, premature optimization.
The author talks about non of the downsides of their approach. They are real.
> Yes, but doing the opposite increases the risk of useEffects triggering unnecessarily (and wildly).
useEffect in your component should be rare. Effects should not come from watching state/props. Effects should come from interactions.
> I strongly disagree. The consequences of not using it by default, then arriving at a case where it matters, are so much bigger than the minor performance impact using it "everywhere" has.
Explains why your viewpoint currently aligns with the author. I can tell from what you've said so far you use useEffect too much, which causes you to rely on referential equality more.
> But you need to have experienced this in a large and complex application to really feel it, I suppose.
Assume I have?
The author talks about non of the downsides of their approach. They are real.
> Yes, but doing the opposite increases the risk of useEffects triggering unnecessarily (and wildly).
useEffect in your component should be rare. Effects should not come from watching state/props. Effects should come from interactions.
> I strongly disagree. The consequences of not using it by default, then arriving at a case where it matters, are so much bigger than the minor performance impact using it "everywhere" has.
Explains why your viewpoint currently aligns with the author. I can tell from what you've said so far you use useEffect too much, which causes you to rely on referential equality more.
> But you need to have experienced this in a large and complex application to really feel it, I suppose.
Assume I have?