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

Not using useCallback is premature optimization

jnystad.no

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Not using useCallback is premature optimization

#11

Post by cercatrova »

Rodeoclash wrote: post #4

As a long, long time user of React (from back in the days before they even had a decent state management system and we were using libraries like "MartyJS" to handle state) I do feel like React has lost its way a little bit for regular users. What benefits are the hooks providing over class based components to the average user ?. I understand Facebook probably has very unique requirements around performance but 99% of…

I use hooks for animation, which requires setting up and tearing it down. I can do that with an easy hook, while if I had class based components, I'd have to keep track of every single time I want to use an animation, which is duplicated effort. Now multiply that by many different types of hooks, like querying for state, using a network connection (and not forgetting to close it down), etc.

Re: Not using useCallback is premature optimization

#12

Post by tylerhou »

zastrowm wrote: post #10
Rodeoclash wrote: post #8

Earlier quoted context omitted.

This is the exact footgun I ran into yesterday: https://codepen.io/rodeoclash/pen/poLqeYb?editors=1111 Even though `theState` is passed to the dependency array of the parent component which is tracking hidden images, it will still be stale! After a while, I figured out that the child components, where the click originates from, also needed to have the map of deleted images passed to their dependency array. Total foot…

For this specific example the problem is that the handleClick callback is using a stale/cached onImageDeleted callback (which indirectly has old state). If you add onImageDeleted to the handleClick dependency array, it beings to work as you expect.

Would the dependency linter catch this? I assume yes?

Re: Not using useCallback is premature optimization

#13

Post by Rodeoclash »

zastrowm wrote: post #10
Rodeoclash wrote: post #8

Earlier quoted context omitted.

This is the exact footgun I ran into yesterday: https://codepen.io/rodeoclash/pen/poLqeYb?editors=1111 Even though `theState` is passed to the dependency array of the parent component which is tracking hidden images, it will still be stale! After a while, I figured out that the child components, where the click originates from, also needed to have the map of deleted images passed to their dependency array. Total foot…

For this specific example the problem is that the handleClick callback is using a stale/cached onImageDeleted callback (which indirectly has old state). If you add onImageDeleted to the handleClick dependency array, it beings to work as you expect.

Ahh, that's interesting.

Re: Not using useCallback is premature optimization

#14

Post by tpict »

tylerhou wrote: post #12
zastrowm wrote: post #10

Earlier quoted context omitted.

For this specific example the problem is that the handleClick callback is using a stale/cached onImageDeleted callback (which indirectly has old state). If you add onImageDeleted to the handleClick dependency array, it beings to work as you expect.

Would the dependency linter catch this? I assume yes?

Yep, it will flag any references to variables in the outer scope that it doesn’t know for certain are stable.

Re: Not using useCallback is premature optimization

#15

Post by willio58 »

Rodeoclash wrote: post #4

As a long, long time user of React (from back in the days before they even had a decent state management system and we were using libraries like "MartyJS" to handle state) I do feel like React has lost its way a little bit for regular users. What benefits are the hooks providing over class based components to the average user ?. I understand Facebook probably has very unique requirements around performance but 99% of…

I would say the benefit of hooks and function based components is simplicity and ease-of-creation. Less boilerplate, less chance to mess up the life cycle of a component, especially for the vast majority of components that end up being pretty simple anyway.

Re: Not using useCallback is premature optimization

#16

Post by darepublic »

brundolf wrote: post #9

For those pushing back, I wanted to share this talk given at a recent React Conf: https://www.youtube.com/watch?v=lGEMwh32soc The idea (still just an internal prototype) is that one day your compiler might automatically memoize all React components and intermediate values for you. It obviously would be great to skip all the syntax noise, as well as the linter-enforced rules around correctly maintaining dependency arr…

If React does it for me then fine, it's welcome. Until then why would I want to wrap all my functions in a bigger function?

How about we just do this:

import {useObey} from 'react'

// you may see no reason why you need to do this but just do it, not doing what you don't understand is obviously a fool's move.. btw.

const goodFn = useObey(myFn)

^// you'd better do this!

In OP's same article they are saying 'Senior' is just a title. Yeah juniors for sure will add an additional wrapper if you tell them. They'll add a useCallback around their useCallback for good measure. Part of being junior is just saying 'yes, mmhmm' to every thing that the hype train tells them to. I guess they are the real seniors since they listen so well.

You people pushing people to put all their callbacks in wrappers even if there is no discernible reason to, frankly suck and you're really sending the completely wrong message here. As a coder you should feel free to admit when you don't understand why something is told to you, and you should be comfortable not obeying the people who insist you need to just trust in their magic.

Re: Not using useCallback is premature optimization

#17

Post by soft_dev_person »

amccloud wrote: post #6

Following this articles advice will likely make your app render slower than not optimizing at all. Caching everything increases your risk of stale data through misconfiguration. Also the benefits of referential stability only apply to a limited set of components in your overall render tree. Most data structures and components don't need stability. The issue people have with hooks is primarily caused by 99% of folks n…

> Following this articles advice will likely make your app render slower than not optimizing at all.

Yes, but it will not actually matter in >99% of real world cases. And this argument is exactly what the article mentions, premature optimization.

> Caching everything increases your risk of stale data through misconfiguration.

Yes, but doing the opposite increases the risk of useEffects triggering unnecessarily (and wildly).

> The issue people have with hooks is primarily caused by 99% of folks not quite understanding just how sparingly hooks should be used.

I strongly disagree. The consequences of not using it by default, then arriving at a case where it matters, are so much bigger than the minor performance impact using it "everywhere" has.

But you need to have experienced this in a large and complex application to really feel it, I suppose.

Re: Not using useCallback is premature optimization

#18

Post by soft_dev_person »

kareemsabri wrote: post #3

I disagree with the author (and stated as much as recently as yesterday: https://news.ycombinator.com/item?id=32485460#32489682 ). > With thousands of geometries in an interactive map, with lists and tables of items filtered by bounding box and categories, sorted by geodetic distance from wherever you were interested in, the performance issues that arose were never too many uses of useCallback or useMemo. The opposit…

> The author here is taking their very valid and necessary use case for the optimization of memoization - non-trivial and expensive operations - and extrapolating from that to "just use useMemo

I would say that was your extrapolation, also it never says use useMemo everywhere.

You mention memo, which is different from useMemo in React, so I'm not sure if you are conflating them.

Either way, the main point is using useCallback by default, and using useMemo for non-trivial computed values. This will help you when your app grows in complexity.

If you understand hooks and why react triggers renders, you probably know when useCallback would not be necessary. However, most don't, and tend to err on the wrong side. Then they end up in hook hell when some component 6 levels deep need to use that callback function in a useEffect.

Re: Not using useCallback is premature optimization

#19

Post by brundolf »

darepublic wrote: post #16
brundolf wrote: post #9

For those pushing back, I wanted to share this talk given at a recent React Conf: https://www.youtube.com/watch?v=lGEMwh32soc The idea (still just an internal prototype) is that one day your compiler might automatically memoize all React components and intermediate values for you. It obviously would be great to skip all the syntax noise, as well as the linter-enforced rules around correctly maintaining dependency arr…

If React does it for me then fine, it's welcome. Until then why would I want to wrap all my functions in a bigger function? How about we just do this: import {useObey} from 'react' // you may see no reason why you need to do this but just do it, not doing what you don't understand is obviously a fool's move.. btw. const goodFn = useObey(myFn) ^// you'd better do this! In OP's same article they are saying 'Senior' is…

My org just got done investigating the advantages and disadvantages of memoizing by default, and we decided to make it a default policy, because for a large org it's better to have a recommended best-practice that's going to make things perform better more often than not. Devs are still free to do otherwise if they profile and find a case where it causes harm, but frankly I don't see that happening.

The appeal to authority in my original comment is not just deferring to trends or whatever; it's leaning on the deep knowledge (and inside-knowledge!) that a core React team member has of not only React's current implementation, but its underlying intents/philosophy (which informs which paths the team will focus on optimizing, for example), and even its future roadmap. I think it's legitimate to take those things into account, especially in the absence of any significant, concrete evidence showing that the practice in question can cause problems.

Re: Not using useCallback is premature optimization

#20

Post by amccloud »

soft_dev_person wrote: post #17
amccloud wrote: post #6

Following this articles advice will likely make your app render slower than not optimizing at all. Caching everything increases your risk of stale data through misconfiguration. Also the benefits of referential stability only apply to a limited set of components in your overall render tree. Most data structures and components don't need stability. The issue people have with hooks is primarily caused by 99% of folks n…

> Following this articles advice will likely make your app render slower than not optimizing at all. Yes, but it will not actually matter in >99% of real world cases. And this argument is exactly what the article mentions, premature optimization. > Caching everything increases your risk of stale data through misconfiguration. Yes, but doing the opposite increases the risk of useEffects triggering unnecessarily (and w…

> Yes, but it will not actually matter in >99% of real world cases. And this argument is exactly what the article mentions, premature optimization.

The author talks about non of the downsides of their approach. They are real.

> Yes, but doing the opposite increases the risk of useEffects triggering unnecessarily (and wildly).

useEffect in your component should be rare. Effects should not come from watching state/props. Effects should come from interactions.

> I strongly disagree. The consequences of not using it by default, then arriving at a case where it matters, are so much bigger than the minor performance impact using it "everywhere" has.

Explains why your viewpoint currently aligns with the author. I can tell from what you've said so far you use useEffect too much, which causes you to rely on referential equality more.

> But you need to have experienced this in a large and complex application to really feel it, I suppose.

Assume I have?

Post reply on HN