4 ms·

I think the people expressing negativity about hooks are a small minority. Hooks are a massive step up from class component lifetime methods, and the composabil

I think the people expressing negativity about hooks are a small minority. Hooks are a massive step up from class component lifetime methods, and the composability of hooks can lead to some very clean and powerful code if you know what you're doing. We're using hooks at work, with rules-of-hooks linting, and I can't remember the last time we had an issue or bug because of hook semantics

mattkenefick 3y ago
I think you're underestimating that.
nicoburns 3y ago
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.
3cats-in-a-coat 3y ago
I sometimes check React discussions and it's full of new made-up terms about managing issues that are uniquely caused by React or some previous iteration of a React technique. What happened with the simplicity of just "generate some boring ass HTML DOM in JSX, and it applies the diff to the actual DOM". That's it. That's the entire value proposition of React and it needs no hooks, handles, states, immutables, events, data trees, properties, arguments, components, nothing else. Oddly that still works just fine, but no one uses React this way anymore.
- peddap 3y ago
  Only if you're working on super simple projects. Or don't want reusable code. How do you share data fetching logic across components How do you share a common UI functionality like toggling states, starting timers, across components? People are now more concerned about clearly writing business logic while stiching together React lifecycles methods, instead of the other way.
  - 3cats-in-a-coat 3y ago
    Lots of assumptions. And they're all based on the fact React must be some all-encompassing framework, like all other frameworks are or have become, and there's no other way to organize your app, possibly, unless it's dropped from above, from the framework, and is intricately interwoven and coupled with it. But there's another option: don't use React as a framework, use it as a library. And do your modules/components/reuse/fetching in your own plain code, while using React as a display layer. You don't even have to use React for the entire UI.
    - deleted 3y ago
      [deleted]
    - rewmie 3y ago
      > Lots of assumptions. And they're all based on the fact React must be some all-encompassing framework, like all other frameworks are or have become, and there's no other way to organize your app, possibly, unless it's dropped from above, from the framework, and is intricately interwoven and coupled with it. This is a silly argument to make. People don't want to onboard onto a myriad of little reinvented wheels just to put together a GUI. This is well known to be a major mistake, and the root cause of failure of countless projects. People are paid to deliver features and fix bugs, and not to peruse through npm like they are playing Pokemon. React solves their problem by solving developers' problems. Don't you understand the value of using a standardized tool that answers all your problems?
sfvisser 3y ago
React went from class components to function components and from lifetime callbacks to hooks. These concepts are completely orthogonal. There exist design choices that would end up with a different combo. Class components with hooks or function components using lifetime callbacks. Yes, hooks — basically sub components with possible effects and yielding values, or DOM output — are a terrific idea and much more functional and principled than explicit lifetime callbacks. All the dependency arrays and non-conditional checks etc are because of the function components approach and don’t have much to do with hooks. I feel nearly every discussion on hooks mixes this up and makes the whole conversation just weird and confusing.
- troupo 3y ago
  > All the dependency arrays and non-conditional checks etc are because of the function components approach And because of React's design choices. Reactivity can be achieved without explicit dependency lists.

mattkenefick 3y ago

I think you're underestimating that.

nicoburns 3y ago

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.

3cats-in-a-coat 3y ago

I sometimes check React discussions and it's full of new made-up terms about managing issues that are uniquely caused by React or some previous iteration of a React technique. What happened with the simplicity of just "generate some boring ass HTML DOM in JSX, and it applies the diff to the actual DOM". That's it. That's the entire value proposition of React and it needs no hooks, handles, states, immutables, events, data trees, properties, arguments, components, nothing else. Oddly that still works just fine, but no one uses React this way anymore.

peddap 3y ago
Only if you're working on super simple projects. Or don't want reusable code. How do you share data fetching logic across components How do you share a common UI functionality like toggling states, starting timers, across components? People are now more concerned about clearly writing business logic while stiching together React lifecycles methods, instead of the other way.
- 3cats-in-a-coat 3y ago
  Lots of assumptions. And they're all based on the fact React must be some all-encompassing framework, like all other frameworks are or have become, and there's no other way to organize your app, possibly, unless it's dropped from above, from the framework, and is intricately interwoven and coupled with it. But there's another option: don't use React as a framework, use it as a library. And do your modules/components/reuse/fetching in your own plain code, while using React as a display layer. You don't even have to use React for the entire UI.
  - deleted 3y ago
    [deleted]
  - rewmie 3y ago
    > Lots of assumptions. And they're all based on the fact React must be some all-encompassing framework, like all other frameworks are or have become, and there's no other way to organize your app, possibly, unless it's dropped from above, from the framework, and is intricately interwoven and coupled with it. This is a silly argument to make. People don't want to onboard onto a myriad of little reinvented wheels just to put together a GUI. This is well known to be a major mistake, and the root cause of failure of countless projects. People are paid to deliver features and fix bugs, and not to peruse through npm like they are playing Pokemon. React solves their problem by solving developers' problems. Don't you understand the value of using a standardized tool that answers all your problems?

sfvisser 3y ago

React went from class components to function components and from lifetime callbacks to hooks. These concepts are completely orthogonal. There exist design choices that would end up with a different combo. Class components with hooks or function components using lifetime callbacks. Yes, hooks — basically sub components with possible effects and yielding values, or DOM output — are a terrific idea and much more functional and principled than explicit lifetime callbacks. All the dependency arrays and non-conditional checks etc are because of the function components approach and don’t have much to do with hooks. I feel nearly every discussion on hooks mixes this up and makes the whole conversation just weird and confusing.

troupo 3y ago
> All the dependency arrays and non-conditional checks etc are because of the function components approach And because of React's design choices. Reactivity can be achieved without explicit dependency lists.