3 ms·
People say "don't just blindly use React.memo, fix slow renders first." But like... with referential identity being so cheap, blindly applying React.memo should
by rtpg 1y ago
People say "don't just blindly use React.memo, fix slow renders first." But like... with referential identity being so cheap, blindly applying React.memo should be a huge win?
CostPostCache = CostOfCache + CacheHitPercentage * CostWhenHittingCache + CacheMissPercentage * CostPreCache
CostOfCache is pretty cheap compared to the CostPreCache IMO... CostWhenHittingCache is very low... and CacheMissPercentage is also probably pretty low in your typical React component that has more than 2 children node involved. Mathematically it feels like a no-brainer!
"Fix your slow renders first" just feels off. Yes you want to fix slow first renders! You also want to avoid wasting render cycles. These are distinct issues from my view. What am I missing? Why shouldn't React "just" do useMemo by default?
- tkdodo 1y ago> blindly applying React.memo should be a huge win That’s what the react compiler does, and it’s a good idea in that case because the compiler knows how to do it correctly, for _everything_. When humans try to do it, they will likely get it wrong (see the real world example in the article, this is the norm imo).
- rtpg 1y agoI just disagree with the article's premise of: > Adding non-primitive props you get passed into your component to internal dependency arrays is rarely right, because this component has no control over the referential stability of those props. Expecting referential transparency is a fine constraint. Inversely, the useRef technique might lead to its own weirdness where your UI is using some stale composite object that your event handler doesn't see anymore (and I prefer slow perf to chasing down correctness issues because you have a ref _and_ you have some accidental mutability somewhere in the stack _and_ you have stale UIs)