Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We memo all the things (2020)

attardi.org

Post reply on HN
Print view View original

71–80 of 84 posts

Re: We memo all the things (2020)

#71

Post by notpachet »

nfRfqX5n wrote: post #70
notpachet wrote: post #44

Earlier quoted context omitted.

This 100%. I still don't understand why React devs are so infatuated with colocating business logic with the UI that presents the result of that business logic. Sure, in the small (a todo list app? a weekend project?) it's probably a lot easier to reason about if you just jam everything into the same file. But why is it so difficult for people to see that the reason their large application is bloated, untestable, unm…

but hooks allow you to easily move business logic outside of your component. most business logic is simple so people use it inline. isolating it makes it pretty easy to test and reuse

That's true. But to echo the underlying theme of the original blog post, it is difficult to ensure that a large team of developers (of varying skill levels) maintains a consistent approach to this. Different developers likely have different opinions of where that "simple" threshold is that warrants factoring out the business logic. And, when the push of a deadline comes to shove, it is tempting to just throw all the shit in the component with the promise that we'll refactor it at a later date.

More fundamentally, I feel like putting business logic hooks in a component (even simple ones) sacrifices the cleanliness of components as simple stream transformers: input some scalar props, output some HTML. As soon as you start calling hooks within a function component, it's no longer purely functional. You have side effects. And those side effects result in a component that's trickier to debug and trickier to test.

Re: We memo all the things (2020)

#72

Post by TheCoelacanth »

eatonphil wrote: post #33
fouric wrote: post #29

Earlier quoted context omitted.

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

There was never a slowness in the apps I've worked on that came down to requiring memoization in React versus other basic things like doing pagination or other ways of rendering only things that would be displayed at the time for the user.

> pagination or other ways of rendering only things that would be displayed at the time for the user

Well, yes, those are alternate ways to deal performance problems, but they are not necessarily any easier than adding a bit of memoization.

Re: We memo all the things (2020)

#73

Post by nsonha »

notpachet wrote: post #39
psadri wrote: post #37

Earlier quoted context omitted.

What is your proposed alternative?

Not the OP, but in a word: Redux.

no?

If you want state management you use a state management library. If you want optimization, you do memo, or pure component. You don't rely on the fact that some state library does that for you. You don't want your component's performance changes drastically when you refactor to context or whatever

Re: We memo all the things (2020)

#74

Post by TheCoelacanth »

jdjb wrote: post #38
nfRfqX5n wrote: post #19

Earlier quoted context omitted.

the only time I find it to be required is when passing in callbacks to custom hooks with props that may change and you'll notice immediately because the callback will continuously run

If you're using React.useCallback to avoid triggering further hooks down the line, then you're using it wrong. Since React.useCallback is ostensibly just React.useMemo wrapped around a function, this note in the documentation is just as applicable: You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalcu…

You're only using it wrong if you're trying to avoid triggering hooks as something other than a performance optimization.

For example, something like this should work correctly even without useCallback, but you would be constantly re-subscribing for no good reason.

    const callback = useCallback(...);

    useEffect(() => {
        const unsubscribe = subscribe(callback);
        return () => unsubscribe();
    }, [callback]);

Re: We memo all the things (2020)

#75

Post by eatonphil »

TheCoelacanth wrote: post #72
eatonphil wrote: post #33

Earlier quoted context omitted.

There was never a slowness in the apps I've worked on that came down to requiring memoization in React versus other basic things like doing pagination or other ways of rendering only things that would be displayed at the time for the user.

> pagination or other ways of rendering only things that would be displayed at the time for the user Well, yes, those are alternate ways to deal performance problems, but they are not necessarily any easier than adding a bit of memoization.

No those solutions (and problems) were completely tangent to adding memoization. My point is that I've never seen a performance issue where non-memoization was the problem.

Re: We memo all the things (2020)

#76

Post by thrashh »

ramesh31 wrote: post #28
jon-wood wrote: 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.

Yeah but no one should be using shouldComponentUpdate except for rare cases

If you have to consistently replace a framework-managed hook for performance, either the framework is not suited for you, the framework is poorly designed, or you’re using the framework wrong.

Re: We memo all the things (2020)

#77

Post by notpachet »

nsonha wrote: post #73
notpachet wrote: post #39

Earlier quoted context omitted.

Not the OP, but in a word: Redux.

no? If you want state management you use a state management library. If you want optimization, you do memo, or pure component. You don't rely on the fact that some state library does that for you. You don't want your component's performance changes drastically when you refactor to context or whatever

See my response to another comment in this thread. react-redux manages shouldComponentUpdate on your behalf. That's what's being discussed: the pain that comes from custom shouldComponentUpdate implementations. I almost never have to write custom component lifecycle methods when using Redux.

Re: We memo all the things (2020)

#78

Post by CharlesW »

napsterbr wrote: post #40
jasonkillian wrote: post #3

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

> has never rung true with me. Yeah, me neither. I'm seeing first-hand a "large" (but probably not Coinbase-large) webapp dying by 10 thousand cuts. The "you shouldn't care if it rerenders" components are, together, affecting performance. Going back and memoizing everything would be a nightmare and not a viable business solution. Rewrite everything from scratch is also not viable. So we have to live with a sluggish a…

> The conclusion I have, which is personal (YMMV) and based on my own experience, is that modern JS development is fundamentally flawed.

So because web developers using a particular UI library can debate one aspect of using the library, modern JS development is fundamentally flawed unless one transpiles from Elm or ClojureScript?

Re: We memo all the things (2020)

#79

Post by nsonha »

notpachet wrote: post #77
nsonha wrote: post #73

Earlier quoted context omitted.

no? If you want state management you use a state management library. If you want optimization, you do memo, or pure component. You don't rely on the fact that some state library does that for you. You don't want your component's performance changes drastically when you refactor to context or whatever

See my response to another comment in this thread. react-redux manages shouldComponentUpdate on your behalf. That's what's being discussed: the pain that comes from custom shouldComponentUpdate implementations. I almost never have to write custom component lifecycle methods when using Redux.

The people who have a need for redux should already be using it. Are you telling people with a need to optimize their components to conjure up a need for redux, just so that they can use it to kill 2 birds with one stone?

Re: We memo all the things (2020)

#80

Post by notpachet »

nsonha wrote: post #79
notpachet wrote: post #77

Earlier quoted context omitted.

See my response to another comment in this thread. react-redux manages shouldComponentUpdate on your behalf. That's what's being discussed: the pain that comes from custom shouldComponentUpdate implementations. I almost never have to write custom component lifecycle methods when using Redux.

The people who have a need for redux should already be using it. Are you telling people with a need to optimize their components to conjure up a need for redux, just so that they can use it to kill 2 birds with one stone?

I would argue that the people who find themselves maintaining an application that is littered with custom shouldComponentUpdate's (et al) have a clear need for _some_ organizing state management principle, whether that's Redux or MobX or something else.

> 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?

The author specified a performance issue that they're trying to debug, but in my experience it's just as common to waste cycles debugging a "why is my component not updating" issue, which is the flip side of the coin: not enough re-renders, instead of too many. So the way I see it, it is not a performance problem per se, it's a state management problem; poor performance (from spurious rerenders) is just one of the possible symptoms of immature state management.

Post reply on HN