Zhenghao He

I would strongly suggest reading through my extensive post "A (Mostly) Complete Guide to React Rendering Behavior" [0], which walks through what "rendering" actually is, what triggers it, React's default behavior, and ways to optimize the behavior by skipping renders for certain components. The post "When Does React Render Your Component?" [1] is also excellent. The short summary is that React queues a render when you call some form of `setState()`, renders this component, and by default recursively renders all children inside this component too. Everything else is variations on that idea. [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-com… [1] https://www.zhenghao.io/posts/react-rerender

EDIT: Paste this hacky snippet into your browser's console to save all of the links into your clipboard: (() => { let result = [...document.querySelectorAll('td a')] .map((link) => link && !link.href.includes('ycombinator') && !link.href.includes('javascript:void') ? link.href : '' ) .filter(Boolean); result = [...new Set(result)]; result.sort(); copy(result.join('\n\n')); })(); Just to help, here's a compiled-list of all of the links shared here so…

Me, myself: https://www.zhenghao.io/ Check it out if you are interested in JavaScript, TypeScript, or web development in general

It looks like you submitted the wrong link judging by the title, did you mean https://www.zhenghao.io/posts/system-design-interviews instead ?

That's why a number of people (myself included) advocate for overzealous/defensive use of useMemo/useCallback as a means of ensuring that a prop changing is always meaningful. The rationale is summarised here: https://www.zhenghao.io/posts/memo-or-not There are good reasons for _not_ doing this, since using these hooks isn't free; and technically speaking useMemo isn't an identity guarantee (though it currently behaves as one), but I haven't experienced any of the common useEffect pitfalls since adopting this methodology a couple of years ago. But as my sibling comment points out, a lot of the need for this defensive coding would go away if there were more ways of defining equivalence. I hope that one day the record and tuple proposals land, which should help a bit. But i'd also like to see something like Python's __eq__ and __hash__ in JavaScript too - perhaps done in a similar way to [Symbol.iterator].