Hacker News new | ask | show | jobs
by lewisl9029 1699 days ago
I also generally fall on the side of useMemo'ing everything pre-emptively, and this is a good argument for its effects on performance. However I think a more important effect is that preserving references between renders (and lack thereof) now has a direct effect on behavior due to useEffect's dependency list.

If a downstream component's useEffect depends on a prop that hasn't been useMemo'd, their effect will be executed on every render due to the changing reference, and there is nothing that can be done at the downstream component to alter that behavior. This means they'd have to trace the prop back to its source and refactor it to useMemo, which can be a very painful exercise as I'm sure anyone who has done it can attest to. For props that come from third party libraries, this might not even be an option, which is why pre-emptively useMemo'ing is even more crucial for reusable abstractions like shared hooks and components.

And yes, I realize that the React docs currently recommend using useMemo only as a performance optimization, not as a semantic guarantee, but I believe that ship has sailed. There is so much code in the wild today that useMemo and then pass the result to some useEffect downstream, that they can't really afford to break in practice. I think the only practical option at this point is to strengthen the original useMemo with a semantic guarantee, and then introduce a separate useMemoForPerformanceOnly (with a better name) hook that can be used to opt-out of the semantic guarantee to allow React to evict memoized results to optimize for memory usage.