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

41–50 of 84 posts

Re: We memo all the things (2020)

#41

Post by cheeew »

I've normally heeded to the advice from Dan Abramov (https://overreacted.io/before-you-memo/) and KCD (https://kentcdodds.com/blog/usememo-and-usecallback): mainly due to the fact that I figured performance would take a significant hit by using unnecessary React.memo / useMemo calls throughout the codebase.

One negative side-effect I could see as a result of this pattern is devs becoming too reliant on these optimizations and neglecting composition.

But I suppose if the performance gain is substantial enough and DX isn't negatively impacted too much, it could serve as worthwhile-- especially at the level of scale which Coinbase requires.

Re: We memo all the things (2020)

#42

Post by brundolf »

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.

I'm not sure why it would. The profiler will tell you exactly which component is the bottleneck, and you could then go inspect that one for the cause.

Re: We memo all the things (2020)

#43

Post by brundolf »

kecupochren wrote: post #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 bet…

I +1 MobX wherever I see it mentioned, but I have to disagree here:

> having logic and state in the view layer leads to spaghetti code

Sometimes it makes sense to put logic and state in your view components, and the wonderful thing about MobX is that it doesn't care. It lets you freely move your state around to wherever you want it to live: inside components, outside components, in a module-scoped object, in a global store, all of the above. It's just JavaScript objects.

For those fighting with hooks: one of the best things about MobX is that it does all dependency-tracking (for effects, but also for components) automatically and flawlessly. An entire problem-space that's usually easy to mess up just vanishes in front of your eyes. Going back to anything else feels like going back to the dark ages.

Re: We memo all the things (2020)

#44

Post by notpachet »

kecupochren wrote: post #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 bet…

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, unmaintainable, etc is directly due to the blatant violation of separation of concerns that they're parroting?

I feel like part of this is due to some devil's bargain on the part of the React maintainers. They want mindshare, and they know that it's easier to gain mindshare if the behaviour of the app appears simpler, and that appearance of simpler is easier to achieve if the behaviour is relegated to a smaller number of files...

Re: We memo all the things (2020)

#45

Post by morgancmartin »

brundolf wrote: post #43
kecupochren wrote: post #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 bet…

I +1 MobX wherever I see it mentioned, but I have to disagree here: > having logic and state in the view layer leads to spaghetti code Sometimes it makes sense to put logic and state in your view components, and the wonderful thing about MobX is that it doesn't care. It lets you freely move your state around to wherever you want it to live: inside components, outside components, in a module-scoped object, in a global…

I'm not familiar with MobX, but I am a big fan of Jotai (https://jotai.pmnd.rs/). It is a spiritual offshoot of Facebook's experimental(?) Recoil library.

It is a bottom up approach to state. Everything is modeled as atoms. Atoms can be defined in any module and are accessed by simply exporting/importing from/to the module. Simply call the useAtom hook and you're now using that state atom.

Under the covers it is scoped via a top-level React context, I believe.

Atom derivation, read/write, async, it's all there. It also hooks into a lot of other popular state libs like redux, XState, Zustand and many others.

I much prefer it to Redux because there is zero boilerplate and extremely flexible. It can be easy to hang yourself with all the extra rope it gives you if you aren't careful though.

Re: We memo all the things (2020)

#46

Post by kecupochren »

brundolf wrote: post #43
kecupochren wrote: post #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 bet…

I +1 MobX wherever I see it mentioned, but I have to disagree here: > having logic and state in the view layer leads to spaghetti code Sometimes it makes sense to put logic and state in your view components, and the wonderful thing about MobX is that it doesn't care. It lets you freely move your state around to wherever you want it to live: inside components, outside components, in a module-scoped object, in a global…

> Sometimes it makes sense to put logic and state in your view components

Of course, I do that a lot with generic, reusable components. Once I know it's too complex I extract it to model that gets passed through props. Win/win

Re: We memo all the things (2020)

#47

Post by Zababa »

wpietri wrote: post #31
Zababa wrote: post #15

Earlier quoted context omitted.

I've always thought of "premature optimisation" as optimising something that's not your "hot path". If there's no clear hot path, everything is the hot path, and small optimisation gains everywhere are the only thing you're going to get. So at this point, it's not premature. You could also rewrite your code so that there is a clear hot path, but in that case it seems to be React rendering, that's optimised by using m…

How could you not have a hot path? You're saying that you've measured actual usage and discovered that each thing happens to be called exactly the same number of times? That strikes me as extraordinarily improbable.

That's not exactly it. It's more of a "If you have nothing that takes more than 1% of your resources, no single optimisation can get you more than a 1% reduction in your resources". That seem to be how most web apps are: you parse a little bit of HTTP, a little bit of JSON, you validate a few things, you call the database, that does a few things too, you have a bit of business logic, you call the database again, then have a bit of glue code here and there, and finally respond to the user with a little bit of HTTP and maybe some HTML, maybe some JSON.

If that's how your app works and nothing can be optimised significantly, that's usually here where you can make big gains in performance by changing a big thing. One of these big things might be to put a cache in front of it, because a cache hit will be way faster than responding again to the same request. Another could be to change language. For example, from Python to Go. Since Go is (most of the time) a bit faster on everything, you end up being faster everywhere. Or even from Python to PyPy, a faster implementation. Another could be redesigning your program so that you have one single obvious hot path, and then optimising that.

That seem to be the case for them here: no component is taking all of the resources, but by using memo everywhere, all of them take less resources, which leads to a good reduction of resources in general.

Re: We memo all the things (2020)

#49

Post by notpachet »

kecupochren wrote: post #48
notpachet wrote: post #39

Earlier quoted context omitted.

Not the OP, but in a word: Redux.

What? Redux doesn't do any performance optimizations.

Not by itself, but most people who use React + Redux use the (unsurprisingly named) react-redux glue library, too. That does a lot of the "should component update" calculations for you as a function of the computed `map[State/Dispatch]ToProps` result. (There are still some gotchas with caching selectors and so on, but I personally find those a lot easier to implement post-fact than memoizing hook soup codebases once you realize you have a problem.)

Re: We memo all the things (2020)

#50

Post by ramesh31 »

psadri wrote: post #37
ramesh31 wrote: post #28

Earlier quoted context omitted.

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.

What is your proposed alternative?

>What is your proposed alternative?

Precisely what the post describes. Functional components and memoize all the things.

Post reply on HN