We memo all the things (2020)
attardi.org
We memo all the things (2020)
1–10 of 84 posts
Re: We memo all the things (2020)
#2Interesting, I mostly followed this approach which is to basically never use those constructs unless you are 100% certain you know what will happen.
https://kentcdodds.com/blog/usememo-and-usecallback
TLDR;
> Specifically the cost for useCallback and useMemo are that you make the code more complex for your co-workers, you could make a mistake in the dependencies array, and you're potentially making performance worse by invoking the built-in hooks and preventing dependencies and memoized values from being garbage collected. Those are all fine costs to incur if you get the performance benefits necessary, but it's best to measure first.
Re: We memo all the things (2020)
#3This is a great article and I agree with it fully.
The argument that a lot of popular React voices have made, "React is fast and it's prematurely optimizing to worry about memoizing things until a profile shows you need it", has never rung true with me. First and foremost, there's a huge time cost to figuring out what those exact spots that need optimization are, and there's also an educational cost with teaching less experienced engineers how to correctly identify and reason about those locations.
There are only two reasonable arguments for not using `memo`, `useMemo`, and `useCallback`. The first is that it decreases devx and makes the code less readable. This one is true, but it's a very small cost to pay and clearly not the most important thing at stake as it's only a slight net effect. The second argument is that the runtime cost of using these constructs is too high. As far as I can tell, nobody has ever done a profile showing that the runtime cost is significant at all, and the burden of proof lies with those claiming the runtime overhead is significant because it doesn't appear that it is typically when profiling an app.
So, given that the two possible reasons for avoiding `memo`, `useMemo`, and `useCallback` are not convincing, and the possible downsides for not using them are fairly large, I find it best to recommend to engineering teams to just use them consistently everywhere by default.
Re: We memo all the things (2020)
#4I like React a lot and have used it professionally for more than 5 years. First off I mostly haven't needed to memoize any time I can remember in any enterprise (non-SaaS) production or personal apps. But surely CoinBase is at a bigger scale than my apps were/are.
But if it's the case that memoizing is such a good thing to do despite the effort (and I'm not debating that in this question), why is React designed in a way that requires you to opt into it and write the same boilerplate all over the place?
If hooks make this a problem maybe hooks aren't the best (or at least pinnacle) design? (And I really prefer hooks, personally.)
Re: We memo all the things (2020)
#5Interesting, I mostly followed this approach which is to basically never use those constructs unless you are 100% certain you know what will happen. https://kentcdodds.com/blog/usememo-and-usecallback TLDR; > Specifically the cost for useCallback and useMemo are that you make the code more complex for your co-workers, you could make a mistake in the dependencies array, and you're potentially making performance worse…
> you could make a mistake in the dependencies array,
This is an auto-fix with eslint, and when it isn't exactly right (you need a "one way update") you can override that rule.
I would posit that passing a value that is regenerated every render (as opposed to when it actually changes) outside of the component (via props or context) is much more dangerous and likely to create infinite loops. For stuff that stays internal, sure, knock yourself out (until it is required by a useEffect or anything else that needs dependencies).
Re: We memo all the things (2020)
#6This feels to me like another example of how the drive to use nothing but functional components in React is harming readability. Class based components were allowed to define a `shouldComponentUpdate` method which would be called ahead of rendering to decide whether a re-render is needed.
Having the parent component memoise the component instead feels like a step backwards as we're now asking the parent to carry an understanding of a child component's implementation to decide whether re-renders are needed, rather than allowing the child to communicate that up the tree.
Re: We memo all the things (2020)
#7This is an antipattern for a reason. Not only is the code less readable, it builds bad habits of code splitting state management and overall structure. A much better alternative is to just learn to understand the tools you are using better.
Re: We memo all the things (2020)
#8I like React a lot and have used it professionally for more than 5 years. First off I mostly haven't needed to memoize any time I can remember in any enterprise (non-SaaS) production or personal apps. But surely CoinBase is at a bigger scale than my apps were/are. But if it's the case that memoizing is such a good thing to do despite the effort (and I'm not debating that in this question), why is React designed in a…
yeah, I was thinking about this too as someone who's not super familiar with React — why isn't memoing the default behavior?
Re: We memo all the things (2020)
#9I have basically no interest in frontend stuff, but I can't stop staring at this page. I think it's the overall color scheme and that body font. It's gorgeous.
Re: We memo all the things (2020)
#10It certainly feels like a failing of the hooks design that these subjects are so common (I love hooks generally!). When someone introduces a new paradigm that by design has a list of footguns to avoid you can't help but wonder if this was necessary.
Has anyone tried tackling a hooks-like api that fixes the known pitfalls? encapsulating shared logic with hooks is a massive benefit but the subtleties can be difficult to teach to others.