[kareemsabri]

I disagree with the author (and stated as much as recently as yesterday: https://news.ycombinator.com/item?id=32485460#32489682).

> With thousands of geometries in an interactive map, with lists and tables of items filtered by bounding box and categories, sorted by geodetic distance from wherever you were interested in, the performance issues that arose were never too many uses of useCallback or useMemo. The opposite caused issues multiple times however, of the app running haywire (or to a halt) kind.

The author here is taking their very valid and necessary use case for the optimization of memoization - non-trivial and expensive operations - and extrapolating from that to "just use useMemo, it's a best practice". Memoized functions are more complicated to reason about and therefore more bug prone than their alternative. Most client-side apps don't have thousands of records they're iterating over, they have dozens. Throwing around memo because one might one day become big, and you'd pay some performance penalty, doesn't seem prudent to me.

[soft_dev_person]

> The author here is taking their very valid and necessary use case for the optimization of memoization - non-trivial and expensive operations - and extrapolating from that to "just use useMemo

I would say that was your extrapolation, also it never says use useMemo everywhere.

You mention memo, which is different from useMemo in React, so I'm not sure if you are conflating them.

Either way, the main point is using useCallback by default, and using useMemo for non-trivial computed values. This will help you when your app grows in complexity.

If you understand hooks and why react triggers renders, you probably know when useCallback would not be necessary. However, most don't, and tend to err on the wrong side. Then they end up in hook hell when some component 6 levels deep need to use that callback function in a useEffect.