[amccloud]

Following this articles advice will likely make your app render slower than not optimizing at all. Caching everything increases your risk of stale data through misconfiguration. Also the benefits of referential stability only apply to a limited set of components in your overall render tree.

Most data structures and components don't need stability. The issue people have with hooks is primarily caused by 99% of folks not quite understanding just how sparingly hooks should be used.

You should only worry about referential equality once you've profiled a performance issue from some high frequency interaction. This is the only time to useCallback, useMemo, or any form of referential caching.

An element walks into a bar. If your component accepts children or any react elements as props, quite normal, all optimizations around referential equality for its inputs will be flung out the window as that component de-optimizes at every optimization prematurely added.

Another big mistake I see folks of all levels make often is expecting more program design upfront vs. say just managing configurations.

- <Example><Test /></Example>

- <Example onTest={() => {}} />

- <Example test={{}} />

- <Example tests={[]} />

These all have the same render cost, so there is often no reason to extract function handlers/arrays/objects out of the jsx configuration.

[soft_dev_person]

> Following this articles advice will likely make your app render slower than not optimizing at all.

Yes, but it will not actually matter in >99% of real world cases. And this argument is exactly what the article mentions, premature optimization.

> Caching everything increases your risk of stale data through misconfiguration.

Yes, but doing the opposite increases the risk of useEffects triggering unnecessarily (and wildly).

> The issue people have with hooks is primarily caused by 99% of folks not quite understanding just how sparingly hooks should be used.

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.

But you need to have experienced this in a large and complex application to really feel it, I suppose.

[amccloud]

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