Live data from Hacker News

We memo all the things (2020)

attardi.org

21–30 of 84 posts

Re: We memo all the things (2020)

#21
post #6

This 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 u…

the parent doesn't have to memoise the component though. You can do this:

    export default React.memo(function myComponent(props) {
      // implementation
    });
though you would likely want to set displayName before exporting, in reality.

Re: We memo all the things (2020)

#22

Interesting, 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…

The problem with avoiding useCallback is that another hook will bite you: useEffect. If you need to define functions that interact with your component's state, you have to memoize them with useCallback (or useRef) to avoid a useEffect infinite loop.

What's even worse is that if functions passed as props are unstable, your useEffect will run every time the parent component renders — meaning that a component can't trust functions passed into it.

This is one of many reasons I think useEffect is a huge footgun, and I really wish we had a better primitive for causing side effects.

Re: We memo all the things (2020)

#23
I find the state of things in React, pun intended, a bit sad. Hooks are definitely an improvement over class based components but it still suffers from the same issue - having logic and state in the view layer leads to spaghetti code. Not to mention dependency arrays which are easy to get wrong and the weird syntax you end up with everywhere.

I'm a big fan of MobX and it pains me to no end that it didn't took off better. It's a godsend from like 5 years ago and it makes so many of these React pain points disappear.

Instead of adding state to your components here and there, it works outside of the view layer. You define the model, derived computed views, actions and then just use it inside your components. You never ever worry about performance because MobX knows what is used where and it will optimize your renders automatically.

Moreover, dealing with state outside of the view layer makes it much more easier to refactor, reason about and test your app. Sure, you can do the same with Redux but it's 10x more code.

I recommend this article on this topic by the author - https://michel.codes/blogs/ui-as-an-afterthought

Re: We memo all the things (2020)

#24
I created the benchmark for this.

Because in every aspect it seems that React.memo is better. Especially when we are sure of stable argument references.

Even when you add children to the component with memo, the worst case performance will be the same.

https://codesandbox.io/s/react-memo-benchmark-m2bk6?file=/sr...

Re: We memo all the things (2020)

#27

Kind of makes you wonder why React.memo isn't just the default behaviour. https://github.com/facebook/react/issues/14463#issuecomment-... suggests it was meant to be the default behaviour, but was scrapped because it would "break backwards compatibility". No source is given for that claim though.

https://overreacted.io/before-you-memo/

https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

Re: We memo all the things (2020)

#28
post #6

This 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 u…

Have you ever dug through a complex heavily nested application trying to debug a performance issue, only to find a custom shouldComponentUpdate method within every individual component? It makes debugging an absolute nightmare.

Re: We memo all the things (2020)

#29

I 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…

What does "needed" mean in "I mostly haven't needed to memoize any time I can remember"?

Does it mean that that your manager/team lead has never asked you to? Or that your production builds always hit some performance benchmark? Or that your development builds hit that benchmark? Or that you never noticed a qualitative slowdown in your development environment? Or something else?

"Needed" is a word you gotta define when you start talking about performance, unlike discussing functional correctness.

Re: We memo all the things (2020)

#30
> If you’ve ever profiled a React app – even in production mode – you know there is a non-negligible performance impact to every component that renders.

Maybe it's just me, but I've used React for ~5 years and I've never needed to profile an app, since the performance out of the box has always been good enough.

Post reply on HN