[brundolf]

For those pushing back, I wanted to share this talk given at a recent React Conf: https://www.youtube.com/watch?v=lGEMwh32soc

The idea (still just an internal prototype) is that one day your compiler might automatically memoize all React components and intermediate values for you. It obviously would be great to skip all the syntax noise, as well as the linter-enforced rules around correctly maintaining dependency arrays, etc.

But I think a big takeaway from this talk is that the React team sees memoizing as the norm. It is something to do by default, so much so that it may happen without your intervention one day. Immutability and value identity-based comparison are core to React. Violating these is the only way memoization can result in bugs (as some in this thread are worried about), and if you aren't following them then a lot of your React code is only working by accident to begin with, memo or no memo.

[darepublic]

If React does it for me then fine, it's welcome. Until then why would I want to wrap all my functions in a bigger function?

How about we just do this:

import {useObey} from 'react'

// you may see no reason why you need to do this but just do it, not doing what you don't understand is obviously a fool's move.. btw.

const goodFn = useObey(myFn)

^// you'd better do this!

In OP's same article they are saying 'Senior' is just a title. Yeah juniors for sure will add an additional wrapper if you tell them. They'll add a useCallback around their useCallback for good measure. Part of being junior is just saying 'yes, mmhmm' to every thing that the hype train tells them to. I guess they are the real seniors since they listen so well.

You people pushing people to put all their callbacks in wrappers even if there is no discernible reason to, frankly suck and you're really sending the completely wrong message here. As a coder you should feel free to admit when you don't understand why something is told to you, and you should be comfortable not obeying the people who insist you need to just trust in their magic.

[brundolf]

My org just got done investigating the advantages and disadvantages of memoizing by default, and we decided to make it a default policy, because for a large org it's better to have a recommended best-practice that's going to make things perform better more often than not. Devs are still free to do otherwise if they profile and find a case where it causes harm, but frankly I don't see that happening.

The appeal to authority in my original comment is not just deferring to trends or whatever; it's leaning on the deep knowledge (and inside-knowledge!) that a core React team member has of not only React's current implementation, but its underlying intents/philosophy (which informs which paths the team will focus on optimizing, for example), and even its future roadmap. I think it's legitimate to take those things into account, especially in the absence of any significant, concrete evidence showing that the practice in question can cause problems.

[darepublic]

> Devs are still free to do otherwise if they profile and find a case where it causes harm, but frankly I don't see that happening.

> I think it's legitimate to take those things into account, especially in the absence of any significant, concrete evidence showing that the practice in question can cause problems.

To me you are switching the burden of proof around from what it should be. What evidence do you have of the significant, concrete variety that wrapping every callback with useCallback, even if the deps array is empty, boosts performance?

[brundolf]

Re-rendering JSX subtrees is the main performance bottleneck in the majority of React apps. I should add that our decision includes the decision to start adding React.memo() to all components; otherwise, yeah, the benefits in most cases would be pretty small. But with React.memo(), useMemo/useCallback makes our components dramatically less likely to re-render, which again is the single biggest thing you can do for performance in most React apps. The difference is usually not perceptible on high-end dev machines, but a significant portion of our target market uses lower-end mobile devices to visit our site, so being performant-by-default is valuable to us.