3 ms·

I would describe the reasons to useMemo or useCallback as follows, in order of decreasing importance: 1) referential equality of non-primitives (any object, fun

I would describe the reasons to useMemo or useCallback as follows, in order of decreasing importance: 1) referential equality of non-primitives (any object, function, etc.) passed downstream as props and 2) expensive computation. The first one is for me non-optional, and I’ll focus on that (as the second one is self-explanatory). Once you know about the reactive render cycle, it becomes a second nature to never create any object other than via a memo function with declared dependencies. Anything else—any instance of something like <Component someProp={[1, 2, 3]} />—is, to me, just a bug on the caller side, not something to be accommodated. Furthermore, ensuring referential equality has benefits beyond avoiding re-renders (which I would acknowledge should generally be harmless, although are in practice a source of hard to spot issues and loops on occasion). — First, it serves as a clarity aid and documentation for yourself. It helps maintain a mental graph like “caller-provided props A and B are used to compute prop C for a downstream component”. Code organized this way tends to have self-evident refactor routes, and logic naturally localizes into cohesive sub-blocks with clearly defined inputs and outputs. — Second, and it is obviously an ES runtime thing, but it is simply weird to have to reason about objects being essentially the same but different—and if memoization allows me to not have to do it and, with some discipline, make it safe to assume that (() => true) is the same as (() => true), why pass on that opportunity? That said, now that I see an alternative take on this, I will make sure to document my approach in the development guidelines section of the README.

joelg 1y ago
yeah I completely agree, I think there's a whole logic of reasons to using useEffect/useCallback/useMemo that the post didn't acknowledge. personally, I want to have a comprehensive understanding of exactly when and why each of my components re-renders, and to do that I use hooks and design around referential equality. like you said, it's a kind of documentation, more about organization than performance. not to say that this way is intrinsically better! just that the style is appealing for its own reasons
agos 1y ago
> it is obviously an ES runtime thing, but it is simply weird to have to reason about objects being essentially the same but different—and if memoization allows me to not have to do it and, with some discipline, make it safe to assume that (() => true) is the same as (() => true), why pass on that opportunity? it sucks both ways - the default is that stuff is different if it looks the same so you can't not do anything, but the only solution is both a lot of work and really easy to mess up completely. The TC39 Composites proposal[1] would be a great step in the right direction, but it will take years in the best scenario, there's really no guarantee that React will take advantage of it, and it still leaves out a lot of cases (Dates, to name one) [1]: https://github.com/tc39/proposal-composites https://github.com/tc39/proposal-composites
- strogonoff 1y ago
  > the only solution is both a lot of work and really easy to mess up I think the other benefit is enough to justify the effort, though. Essentially, you don’t just make up objects, but instead you define each object’s constructor and all of its inputs. This makes it natural to keep logic contained and easy to shuffle things around when refactoring!

joelg 1y ago

yeah I completely agree, I think there's a whole logic of reasons to using useEffect/useCallback/useMemo that the post didn't acknowledge. personally, I want to have a comprehensive understanding of exactly when and why each of my components re-renders, and to do that I use hooks and design around referential equality. like you said, it's a kind of documentation, more about organization than performance. not to say that this way is intrinsically better! just that the style is appealing for its own reasons

agos 1y ago

> it is obviously an ES runtime thing, but it is simply weird to have to reason about objects being essentially the same but different—and if memoization allows me to not have to do it and, with some discipline, make it safe to assume that (() => true) is the same as (() => true), why pass on that opportunity? it sucks both ways - the default is that stuff is different if it looks the same so you can't not do anything, but the only solution is both a lot of work and really easy to mess up completely. The TC39 Composites proposal[1] would be a great step in the right direction, but it will take years in the best scenario, there's really no guarantee that React will take advantage of it, and it still leaves out a lot of cases (Dates, to name one) [1]: https://github.com/tc39/proposal-composites https://github.com/tc39/proposal-composites

strogonoff 1y ago
> the only solution is both a lot of work and really easy to mess up I think the other benefit is enough to justify the effort, though. Essentially, you don’t just make up objects, but instead you define each object’s constructor and all of its inputs. This makes it natural to keep logic contained and easy to shuffle things around when refactoring!