[HN Gopher] Not using useCallback is premature optimization
       ___________________________________________________________________
        
       Not using useCallback is premature optimization
        
       Author : soft_dev_person
       Score  : 8 points
       Date   : 2022-08-17 17:42 UTC (5 hours ago)
        
 (HTM) web link (jnystad.no)
 (TXT) w3m dump (jnystad.no)
        
       | kareemsabri wrote:
       | 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 opposite caused issues multiple times
       | however, of the app running haywire (or to a halt) kind.
       | 
       | 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,
       | it's a best practice". Memoized functions are more complicated to
       | reason about and therefore more bug prone than their alternative.
       | Most client-side apps _don 't_ have thousands of records they're
       | iterating over, they have dozens. Throwing around memo because
       | one might one day become big, and you'd pay some performance
       | penalty, doesn't seem prudent to me.
        
       | Rodeoclash wrote:
       | 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 people using
       | the framework probably don 't suffer from these problems but have
       | to put up with the downsides of the occasional weirdness that
       | hooks introduce.
       | 
       | Example, the way you have to handle useCallback is something that
       | bit me very recently. I had a parent component tracking deleted
       | gallery items as a map of ids and a boolean indicating if the
       | image had been deleted. For some reason I couldn't figure out why
       | the deletion map was always stale in the callback. Sure I had a
       | useCallback around it but I'd correctly added the state variable
       | in the dependency array of the useCallback hook.
       | 
       | Well, it turns out I need to pass the deletion map down to the
       | child <Image /> components of the gallery where the deletion was
       | called from because they also had a useCallback in them. The
       | child image components have to know about all the images that
       | have been deleted so that the parent component has the correct up
       | to date state. Crazy!
       | 
       | I get that it's Facebooks project and they can do what they want
       | with it, but I have 6+ years sunk into using the framework now,
       | it's a lot to throw away. That said, I have high hopes for the
       | combination of LiveView and Web Component based libraries like
       | https://shoelace.style/
        
         | tpict wrote:
         | Do you have a reduced code sample? I can't quite picture the
         | stale state issue.
         | 
         | (I suppose this is a good example in favour of the opposing
         | "useCallback is premature optimisation" opinion)
        
       | rektide wrote:
       | I remember having this discussion with less senior devs, & not
       | convincing them at all of the value of building a stable
       | practice. Having to think about whether we do things one way or
       | another, having to decide, making the reasons for the decision
       | known have huge costs. Re-evaluating as we make further changes
       | has a significant chance of screw up.
       | 
       | Having reliable 99% straight shots that encompass a variety of
       | cases is so preferrable. I've been trying to advocate for
       | consistent, low-control-flow decision making for so long, & this
       | feels like what should have been an easy win example for me to
       | make the case on. Im glad to see the topic/example come up again,
       | with a much better specific elaboration.
        
       ___________________________________________________________________
       (page generated 2022-08-17 23:02 UTC)