4 ms·

I think they're a bit of a mixed blessing. The way they can decouple business logic from view logic is absolutely fantastic. But having to wrap everything in us

I think they're a bit of a mixed blessing. The way they can decouple business logic from view logic is absolutely fantastic. But having to wrap everything in useCallback and useMemo to avoid re-renders is a bit of a footgun and a step backwards from class components.

threatofrain 3y ago
The React team is testing out a compiler time approach to useMemo instead.
bcherny 3y ago
My understanding is you don’t usually need useMemo and useCallback, unless you’re seeing performance issues and your profiler is pointing at un-memoized code as the culprit.
SkyPuncher 3y ago
We wrap very little in those methods and things are just fine.
jacobedawson 3y ago
Best practice in general is not to use either of those hooks unless you notice performance issues, or have a good reason to, React is optimized pretty well and unless there are serious numbers of rerenders happening they aren't noticeable. Josh Comeau has a nice overview of useMemo and useCallback, one of my favourites: https://www.joshwcomeau.com/react/usememo-and-usecallback/#when-to-use-these-hooks-6 https://www.joshwcomeau.com/react/usememo-and-usecallback/#w...
- nicoburns 3y ago
  The problem is that they don't work to fix performance issues unless they're implemented all the way up the tree. So if you have a perf-sensitive view, then you'd better hope that your "application frame" components (or anything higher than the perf-sensitive component in the tree) are optimised to avoid re-renders. And it's a massive pain to retrofit this in later if you haven't been strict with it from the start.
kfrane 3y ago
Hooks are a step in the right direction, I just have a feeling that having to wrap in useCallback and useMemo and having to add dependencies manually can't be the final step of web app development. I look into the author's suggestions for the next generation of hook api in other libraries. However, I still don't want to rely on those libraries in large long living projects.
tobr 3y ago
> The way they can decouple business logic from view logic is absolutely fantastic. It’s a great idea to decouple business logic from view logic, but then hooks are the wrong place to start. Last time I checked, you couldn’t use them at all outside of a React component. That’s just a terrible place to put your business logic if you want it to be isolated from the specifics of your view. I’ve mostly moved away from React, so maybe this has changed recently, but it seems difficult considering the fundamentals of their design.
- nicoburns 3y ago
  The problem that hooks solve really nicely is when you want per-component state, but you duplicated versions of that state (and surrounding logic) in different components. With class-based React components you had to use things like higher order components, or manually add the state properties into each component. With hooks this is all neatly abstracted away. You don't always need this. Sometimes your business logic can just be a pure function. But where you do (and IME this is quite common), hooks are super nice.
ElKrist 3y ago
Like others I disagree that you have to wrap _everything_ in useCallback/useMemo. However saying you only need those for performance reasons is wrong. There are cases where avoiding re-rendering (thanks to useCallback) is avoiding an infinite loop. I created a codesandbox[1] to illustrate this. Wrapping the "reset" function in a useCallback solves the infinite loop. If your initial reaction is: "you should not create logic like this" or "you're adding unnecessary stuff" please note that this is a stripped down version of a real use case, where things make more sense. The point is that it's hard to come up with a rule as to when to use useCallback. The best I can think about is: "if you don't have direct vision on where your function will be consumed, wrap it in useCallback". For example, when your function is defined and returned in a hook or defined in a parent component and given to children. The point is that any of those children/consumers could have this function in a useEffect and so list it as a dependency of this useEffect. [1]: Warning, clicking "Start" creates an infinite loop in your browser. https://codesandbox.io/s/intelligent-rgb-6nfrt3 https://codesandbox.io/s/intelligent-rgb-6nfrt3
- pcthrowaway 3y ago
  This example doesn't resemble anything someone would actually write though. There's no reason to reset before setting data again, and I'm not sure why you'd even consider putting the functions in the dependency array for the useEffect in usePets. I can imagine reasons you'd want to setData in a useEffect (maybe when something else changes, or the user performs some interaction, you fetch new data and then set it), but the dependency would be the thing that indicates that action has happened, and not a reset function returned by a custom hook coupled with your data and setter function.
  - ElKrist 3y ago
    I tried to address your type of reaction in my "If your initial reaction is(...)" sentence, but that failed. The point is not that this code is good or bad. It's that it is possible to write such hard to predict code. Remember this is a stripped down version of some code running in production. Now to address your specific points anyway: "There's no reason to reset again": in the non-stripped down version, the hooks rely on a third hook (let's call it "useToken") and needs to react accordingly to this change of token to fetch new data "I'm not sure why you'd even consider putting the functions in the dependency array for the useEffect in usePets.": unfortunately react-hooks/exhaustive-deps is here to warn you. You can disable or ignore it but I guess you expose yourself to a real missing dependency? Genuinely very keen to hear if you use this rule in your projects and what you do in such cases (where you use a function in the useEffect but do not want to re-run the effect each time this fn changes). To me it's such a weird/unnatural thing to list functions as dependencies because almost all the time functions do not change.

threatofrain 3y ago

The React team is testing out a compiler time approach to useMemo instead.

bcherny 3y ago

My understanding is you don’t usually need useMemo and useCallback, unless you’re seeing performance issues and your profiler is pointing at un-memoized code as the culprit.

SkyPuncher 3y ago

We wrap very little in those methods and things are just fine.

jacobedawson 3y ago

Best practice in general is not to use either of those hooks unless you notice performance issues, or have a good reason to, React is optimized pretty well and unless there are serious numbers of rerenders happening they aren't noticeable. Josh Comeau has a nice overview of useMemo and useCallback, one of my favourites: https://www.joshwcomeau.com/react/usememo-and-usecallback/#when-to-use-these-hooks-6 https://www.joshwcomeau.com/react/usememo-and-usecallback/#w...

nicoburns 3y ago
The problem is that they don't work to fix performance issues unless they're implemented all the way up the tree. So if you have a perf-sensitive view, then you'd better hope that your "application frame" components (or anything higher than the perf-sensitive component in the tree) are optimised to avoid re-renders. And it's a massive pain to retrofit this in later if you haven't been strict with it from the start.

kfrane 3y ago

Hooks are a step in the right direction, I just have a feeling that having to wrap in useCallback and useMemo and having to add dependencies manually can't be the final step of web app development. I look into the author's suggestions for the next generation of hook api in other libraries. However, I still don't want to rely on those libraries in large long living projects.

tobr 3y ago

> The way they can decouple business logic from view logic is absolutely fantastic. It’s a great idea to decouple business logic from view logic, but then hooks are the wrong place to start. Last time I checked, you couldn’t use them at all outside of a React component. That’s just a terrible place to put your business logic if you want it to be isolated from the specifics of your view. I’ve mostly moved away from React, so maybe this has changed recently, but it seems difficult considering the fundamentals of their design.

nicoburns 3y ago
The problem that hooks solve really nicely is when you want per-component state, but you duplicated versions of that state (and surrounding logic) in different components. With class-based React components you had to use things like higher order components, or manually add the state properties into each component. With hooks this is all neatly abstracted away. You don't always need this. Sometimes your business logic can just be a pure function. But where you do (and IME this is quite common), hooks are super nice.

ElKrist 3y ago

Like others I disagree that you have to wrap _everything_ in useCallback/useMemo. However saying you only need those for performance reasons is wrong. There are cases where avoiding re-rendering (thanks to useCallback) is avoiding an infinite loop. I created a codesandbox[1] to illustrate this. Wrapping the "reset" function in a useCallback solves the infinite loop. If your initial reaction is: "you should not create logic like this" or "you're adding unnecessary stuff" please note that this is a stripped down version of a real use case, where things make more sense. The point is that it's hard to come up with a rule as to when to use useCallback. The best I can think about is: "if you don't have direct vision on where your function will be consumed, wrap it in useCallback". For example, when your function is defined and returned in a hook or defined in a parent component and given to children. The point is that any of those children/consumers could have this function in a useEffect and so list it as a dependency of this useEffect. [1]: Warning, clicking "Start" creates an infinite loop in your browser. https://codesandbox.io/s/intelligent-rgb-6nfrt3 https://codesandbox.io/s/intelligent-rgb-6nfrt3

pcthrowaway 3y ago
This example doesn't resemble anything someone would actually write though. There's no reason to reset before setting data again, and I'm not sure why you'd even consider putting the functions in the dependency array for the useEffect in usePets. I can imagine reasons you'd want to setData in a useEffect (maybe when something else changes, or the user performs some interaction, you fetch new data and then set it), but the dependency would be the thing that indicates that action has happened, and not a reset function returned by a custom hook coupled with your data and setter function.
- ElKrist 3y ago
  I tried to address your type of reaction in my "If your initial reaction is(...)" sentence, but that failed. The point is not that this code is good or bad. It's that it is possible to write such hard to predict code. Remember this is a stripped down version of some code running in production. Now to address your specific points anyway: "There's no reason to reset again": in the non-stripped down version, the hooks rely on a third hook (let's call it "useToken") and needs to react accordingly to this change of token to fetch new data "I'm not sure why you'd even consider putting the functions in the dependency array for the useEffect in usePets.": unfortunately react-hooks/exhaustive-deps is here to warn you. You can disable or ignore it but I guess you expose yourself to a real missing dependency? Genuinely very keen to hear if you use this rule in your projects and what you do in such cases (where you use a function in the useEffect but do not want to re-run the effect each time this fn changes). To me it's such a weird/unnatural thing to list functions as dependencies because almost all the time functions do not change.