That's my point. Aiming for 1ms performance gains increases the complexity of the code while being unnoticeable by the end user. It's an endeavor that harms the DX for no noticeable benefit.

In terms of causing rerenders of the component tree, those rerenders would happen anyways.

The only reason a component rerenders is because a state change happened in it or above it. Once that happens, the entire tree underneath rerenders (memoizatikn and server-side components notwithstanding), whether something in them changed or not.

Take a look at Mark Erikson's excellent post about rendering at https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior for more details.

I'm not saying that these optimizations should never be done. Optimization is an important part of the development lifecycle -- when the need arises. If something feels laggy, look at the profiler, find the offending component, then pinpoint what makes the most sense to improve performance there.

I'm warning about premature optimization. Adding code for *noticeable* benefit makes sense. Adding code for no noticeable benefit does not.

(Certainly pulling the function out of the component would be a nice win. It's typically an edge case, since most handlers impact a component's state or its properties, so I didn't consider that as the route most people would consider for optimization.)