7 ms·

I absolutely love hooks and don't want to use the `React.Component` class ever again. And yes, hooks need to be grasped, they're quite something else. But once

I absolutely love hooks and don't want to use the `React.Component` class ever again. And yes, hooks need to be grasped, they're quite something else. But once you get the hang of hooks, they're very simple to understand. OP seems to be a bit stuck in a hole. If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure. Believe me, it all can be simplified. Just rinse and repeat until you are satisfied with the outcome. That's when the "aha!" moment comes. At the moment I only use `useEffect`, `useState`, `useRef` — the rest is unneeded so far even in my large-ish application. P.S. sorry for the puns!

wokwokwok 7y ago
That seems a bit unfair. There are some weird edge cases with useEffect, no question. I don’t think they’re bad enough to want to go back to using classes... but I think the OPs post was a bit more specific than you’re giving them credit for, and they stuff like useAsyncEffect exists because it is a common pain point. For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha https://stackblitz.com/edit/react-ts-zhvuha The behaviour is weird sometimes; just because you can use the trivial use case easily doesn’t mean you won’t stumble, and if you do, good luck trying to understand what went wrong. > ...they're very simple to understand... They’re not simple. They just superficially appear simple, which is good enough most of the time. I think it’s entirely fair to complain that’s not ideal... even if you still think there’s a major benefit to the trade off compared to classes (which I do think is true too). ...but I’m very sympathetic to people hitting edge cases.
- bcyn 7y ago
  > For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha https://stackblitz.com/edit/react-ts-zhvuha On this particular point, the reasoning is that refs are meant for values that don't need to trigger a rerender[1] -- an escape hatch, rather than something you reach for by default. In that sandbox, you can accomplish what you mean to accomplish by using state rather than a ref. [1] https://github.com/facebook/react/issues/14387#issuecomment-503616820 https://github.com/facebook/react/issues/14387#issuecomment-...
  - dumbmatter 7y ago
    I've seen a ton of people make that mistake, though. I think it's because what you write is accurate - "refs are meant for values that don't need to trigger a rerender" - but most people think of refs (or at least refs of DOM elements, which for many people are the only refs they ever use) as just a way to access a DOM element. They expect it to just be a DOM element in a normal variable. I'm not sure if there is a less confusing way of doing it, but it's damn confusing.
    - PKop 7y ago
      But it's a pretty straightforward rule once you know it right? This is simply a matter of reading the docs (or making the mistake until you learn). Not an inherently more complex characteristic than, say, Class component lifecycle methods, which also required understanding their rules and reading the docs. Once you know refs updates won't re-render, you won't make this mistake. I don't understand why "a thing you need to learn then you're good" is somehow inherently more complicated than ... other apis that you need to also learn. > but most people think of refs as... This sounds like Dan Abramov's comment that some of the struggles with hooks is from people who have experience with react without hooks, vs people coming new to the whole thing. So maybe it's about relaxing pre-conceived notions until experience takes over.
      - dumbmatter 7y ago
        Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune. Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated. Now that I'm thinking about it... what is the reason that DOM refs and other refs need to be handled by the same concept? Every time I make a DOM ref, I'm doing something with it in a hook like useEffect. Why make me jump through hoops to re-run the hook if the DOM ref changes? (I recognize there are probably good answers to those questions, the React folks are great, I just don't know the answers! Is it just to avoid introducing one more "type of thing", and instead making refs and DOM refs the same "thing"?)
- mst 7y ago
  I suspect this may be one of those cases where there's an 'aha' moment involved, and people who get that moment early find it simple to understand, people who haven't got to that moment yet are going argh, and people who got to it late sigh and/or write "yet another X tutorial" in the hopes that how they got their aha moment will work for other people. The classic X here, of course, is monads. But as personal examples, it took me ages of headbanging to get the 'aha' moment for git, even though a bunch of people I know got it almost immediately. In the case of hooks, once I built a mental model of how they were (theoretically) implemented, I went 'ooh' and found them obvious and relatively easy from then on. It looks to me like the author of this piece didn't have that luck, and so for him, they're not simple (although maybe later, post-aha-moment, they will be). tl;dr: "They seem simple to understand once you understand them, but are mystifying up until that point" seems to me to be the most likely hypothesis here.
- sprokuski 7y ago
  I think you can make that first useEffect block fire by passing in an empty array as your params. This should run the code block on mount. To run a function on unmount, return it from the same useEffect with the empty array params.
  - RussianCow 7y ago
    My frustration with this is that it's completely unintuitive and doesn't read very well. Yes, you'll get used to it once you work with hooks enough, but at first glance, the empty array and the return value from the function passed to `useEffect` don't give me any useful information as to what the code is actually doing. It's an entirely React-specific abstraction that forces you to memorize a bunch of obtuse rules in order to use it effectively, as opposed to building on simpler primitives, which had previously always been the appeal of React.
jtreminio 7y ago
We're slowly refactoring our class-heavy React app to functional components with hooks. One thing we haven't been able to replace, though, are classes that depend on refs. How to do this, since there's no instance with functions like there are with classes?
- bcyn 7y ago
  useRef was designed for this purpose: https://reactjs.org/docs/hooks-reference.html#useref https://reactjs.org/docs/hooks-reference.html#useref If you ran into something that isn't quite covered by this hook, I'm also curious! Can you write a minimal example in codesandbox and share?
- acemarke 7y ago
  That's what the very-rarely-used `useImperativeHandle` hook is for - exposing "instance methods" from function components: https://reactjs.org/docs/hooks-reference.html#useimperativehandle https://reactjs.org/docs/hooks-reference.html#useimperativeh...
marmada 7y ago
I don't understand the hate against class based components. React class-based components are dead simple to understand.
- s_y_n_t_a_x 7y ago
  Nothing is simpler than a function. Easier to write, debug, and test. * Removed "pure" to make my main point clear.
  - RussianCow 7y ago
    But functions that use hooks aren't pure because hooks break referential transparency.
  - istoica 7y ago
    How are your functions pure if inside them you call `useEffect`, `useState` ? Where is pureness when at first look they generate side effects, or am I missing something ?
    - s_y_n_t_a_x 7y ago
      Not all functions needs hooks, not all hooks break pureness. But my point was functions are simpler in all those scenarios, pure or not. Edited my comment to reflect that.
      - csande17 7y ago
        > not all hooks break pureness Sure, if you define a function called useWhatever that doesn't actually call any hooks, that might be a pure function. But the restrictions described in https://reactjs.org/docs/hooks-rules.html https://reactjs.org/docs/hooks-rules.html are not restrictions that pure functions have.
  - shantly 7y ago
    Simplicity does not necessarily imply clarity.
ohyes 7y ago
> If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure “Just burn it to the ground and start over,” isn’t an inspiring endorsement of the methodology...
dynamite-ready 7y ago
`useContext` is excellent. React.context is a solid alternative to the likes of Redux and Apollo, but takes a fair amount of boilerplate to add to a class based React component. But with `useContext`, applying global state is a breeze. A lot easier to manage than Redux, at the very least. The only real dislike I have, is in how `useEffect` confuses the React lifecycle. It took me a little while to grok the lifecycle idea, but it was/is a useful way to conceptualise what happens to your components at runtime. But now, you have to remap all that knowledge to the hooks workflow. It's not a huge challenge, but it's yet another overhead. Indeed, starting out, our team ran into a number of issues with infinite rendering loops and the like. Took a fair amount of reading to discover where the pitfalls were.
- fishnchips 7y ago
  I understand how contexts can replace Redux, but can you please elaborate how they can be used instead of Apollo? Do you mean the whole of Apollo or Apollo local state?
  - acemarke 7y ago
    Note that context and useReducer do _not_ completely replace Redux. See the following resources for more details: - Mark Erikson - Reactathon 2019: The State of Redux (https://blog.isquaredsoftware.com/2019/03/presentation-state-of-redux/ https://blog.isquaredsoftware.com/2019/03/presentation-state...) - Mark Erikson: Redux - Not Dead Yet! (https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...) - Dave Ceddia: React Context API vs Redux (https://daveceddia.com/context-api-vs-redux/ https://daveceddia.com/context-api-vs-redux/) - Mike Green: You Might Not Need Redux (But You Can’t Replace It With Hooks) (https://www.simplethread.com/cant-replace-redux-with-hooks/ https://www.simplethread.com/cant-replace-redux-with-hooks/) - Sergey Ryzhov: From Redux to Hooks: A Case Study (https://staleclosures.dev/from-redux-to-hooks-case-study/ https://staleclosures.dev/from-redux-to-hooks-case-study/) - Eric Elliott: Do React Hooks Replace Redux? (https://medium.com/javascript-scene/do-react-hooks-replace-redux-210bab340672 https://medium.com/javascript-scene/do-react-hooks-replace-r...) - Chris Achard: Can You Replace Redux with React Hooks?](https://dev.to/chrisachard/can-you-replace-redux-with-react-hooks-20gm https://dev.to/chrisachard/can-you-replace-redux-with-react-...)
wilsonrocks 7y ago
I certainly found on one occasion where I felt I had to break the laws of hooks, that it worked much better split into two components.

wokwokwok 7y ago

That seems a bit unfair. There are some weird edge cases with useEffect, no question. I don’t think they’re bad enough to want to go back to using classes... but I think the OPs post was a bit more specific than you’re giving them credit for, and they stuff like useAsyncEffect exists because it is a common pain point. For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha https://stackblitz.com/edit/react-ts-zhvuha The behaviour is weird sometimes; just because you can use the trivial use case easily doesn’t mean you won’t stumble, and if you do, good luck trying to understand what went wrong. > ...they're very simple to understand... They’re not simple. They just superficially appear simple, which is good enough most of the time. I think it’s entirely fair to complain that’s not ideal... even if you still think there’s a major benefit to the trade off compared to classes (which I do think is true too). ...but I’m very sympathetic to people hitting edge cases.

bcyn 7y ago
> For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha https://stackblitz.com/edit/react-ts-zhvuha On this particular point, the reasoning is that refs are meant for values that don't need to trigger a rerender[1] -- an escape hatch, rather than something you reach for by default. In that sandbox, you can accomplish what you mean to accomplish by using state rather than a ref. [1] https://github.com/facebook/react/issues/14387#issuecomment-503616820 https://github.com/facebook/react/issues/14387#issuecomment-...
- dumbmatter 7y ago
  I've seen a ton of people make that mistake, though. I think it's because what you write is accurate - "refs are meant for values that don't need to trigger a rerender" - but most people think of refs (or at least refs of DOM elements, which for many people are the only refs they ever use) as just a way to access a DOM element. They expect it to just be a DOM element in a normal variable. I'm not sure if there is a less confusing way of doing it, but it's damn confusing.
  - PKop 7y ago
    But it's a pretty straightforward rule once you know it right? This is simply a matter of reading the docs (or making the mistake until you learn). Not an inherently more complex characteristic than, say, Class component lifecycle methods, which also required understanding their rules and reading the docs. Once you know refs updates won't re-render, you won't make this mistake. I don't understand why "a thing you need to learn then you're good" is somehow inherently more complicated than ... other apis that you need to also learn. > but most people think of refs as... This sounds like Dan Abramov's comment that some of the struggles with hooks is from people who have experience with react without hooks, vs people coming new to the whole thing. So maybe it's about relaxing pre-conceived notions until experience takes over.
    - dumbmatter 7y ago
      Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune. Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated. Now that I'm thinking about it... what is the reason that DOM refs and other refs need to be handled by the same concept? Every time I make a DOM ref, I'm doing something with it in a hook like useEffect. Why make me jump through hoops to re-run the hook if the DOM ref changes? (I recognize there are probably good answers to those questions, the React folks are great, I just don't know the answers! Is it just to avoid introducing one more "type of thing", and instead making refs and DOM refs the same "thing"?)
mst 7y ago
I suspect this may be one of those cases where there's an 'aha' moment involved, and people who get that moment early find it simple to understand, people who haven't got to that moment yet are going argh, and people who got to it late sigh and/or write "yet another X tutorial" in the hopes that how they got their aha moment will work for other people. The classic X here, of course, is monads. But as personal examples, it took me ages of headbanging to get the 'aha' moment for git, even though a bunch of people I know got it almost immediately. In the case of hooks, once I built a mental model of how they were (theoretically) implemented, I went 'ooh' and found them obvious and relatively easy from then on. It looks to me like the author of this piece didn't have that luck, and so for him, they're not simple (although maybe later, post-aha-moment, they will be). tl;dr: "They seem simple to understand once you understand them, but are mystifying up until that point" seems to me to be the most likely hypothesis here.
sprokuski 7y ago
I think you can make that first useEffect block fire by passing in an empty array as your params. This should run the code block on mount. To run a function on unmount, return it from the same useEffect with the empty array params.
- RussianCow 7y ago
  My frustration with this is that it's completely unintuitive and doesn't read very well. Yes, you'll get used to it once you work with hooks enough, but at first glance, the empty array and the return value from the function passed to `useEffect` don't give me any useful information as to what the code is actually doing. It's an entirely React-specific abstraction that forces you to memorize a bunch of obtuse rules in order to use it effectively, as opposed to building on simpler primitives, which had previously always been the appeal of React.

jtreminio 7y ago

We're slowly refactoring our class-heavy React app to functional components with hooks. One thing we haven't been able to replace, though, are classes that depend on refs. How to do this, since there's no instance with functions like there are with classes?

bcyn 7y ago
useRef was designed for this purpose: https://reactjs.org/docs/hooks-reference.html#useref https://reactjs.org/docs/hooks-reference.html#useref If you ran into something that isn't quite covered by this hook, I'm also curious! Can you write a minimal example in codesandbox and share?
acemarke 7y ago
That's what the very-rarely-used `useImperativeHandle` hook is for - exposing "instance methods" from function components: https://reactjs.org/docs/hooks-reference.html#useimperativehandle https://reactjs.org/docs/hooks-reference.html#useimperativeh...

marmada 7y ago

I don't understand the hate against class based components. React class-based components are dead simple to understand.

s_y_n_t_a_x 7y ago
Nothing is simpler than a function. Easier to write, debug, and test. * Removed "pure" to make my main point clear.
- RussianCow 7y ago
  But functions that use hooks aren't pure because hooks break referential transparency.
- istoica 7y ago
  How are your functions pure if inside them you call `useEffect`, `useState` ? Where is pureness when at first look they generate side effects, or am I missing something ?
  - s_y_n_t_a_x 7y ago
    Not all functions needs hooks, not all hooks break pureness. But my point was functions are simpler in all those scenarios, pure or not. Edited my comment to reflect that.
    - csande17 7y ago
      > not all hooks break pureness Sure, if you define a function called useWhatever that doesn't actually call any hooks, that might be a pure function. But the restrictions described in https://reactjs.org/docs/hooks-rules.html https://reactjs.org/docs/hooks-rules.html are not restrictions that pure functions have.
- shantly 7y ago
  Simplicity does not necessarily imply clarity.

ohyes 7y ago

> If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure “Just burn it to the ground and start over,” isn’t an inspiring endorsement of the methodology...

dynamite-ready 7y ago

`useContext` is excellent. React.context is a solid alternative to the likes of Redux and Apollo, but takes a fair amount of boilerplate to add to a class based React component. But with `useContext`, applying global state is a breeze. A lot easier to manage than Redux, at the very least. The only real dislike I have, is in how `useEffect` confuses the React lifecycle. It took me a little while to grok the lifecycle idea, but it was/is a useful way to conceptualise what happens to your components at runtime. But now, you have to remap all that knowledge to the hooks workflow. It's not a huge challenge, but it's yet another overhead. Indeed, starting out, our team ran into a number of issues with infinite rendering loops and the like. Took a fair amount of reading to discover where the pitfalls were.

fishnchips 7y ago
I understand how contexts can replace Redux, but can you please elaborate how they can be used instead of Apollo? Do you mean the whole of Apollo or Apollo local state?
- acemarke 7y ago
  Note that context and useReducer do _not_ completely replace Redux. See the following resources for more details: - Mark Erikson - Reactathon 2019: The State of Redux (https://blog.isquaredsoftware.com/2019/03/presentation-state-of-redux/ https://blog.isquaredsoftware.com/2019/03/presentation-state...) - Mark Erikson: Redux - Not Dead Yet! (https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...) - Dave Ceddia: React Context API vs Redux (https://daveceddia.com/context-api-vs-redux/ https://daveceddia.com/context-api-vs-redux/) - Mike Green: You Might Not Need Redux (But You Can’t Replace It With Hooks) (https://www.simplethread.com/cant-replace-redux-with-hooks/ https://www.simplethread.com/cant-replace-redux-with-hooks/) - Sergey Ryzhov: From Redux to Hooks: A Case Study (https://staleclosures.dev/from-redux-to-hooks-case-study/ https://staleclosures.dev/from-redux-to-hooks-case-study/) - Eric Elliott: Do React Hooks Replace Redux? (https://medium.com/javascript-scene/do-react-hooks-replace-redux-210bab340672 https://medium.com/javascript-scene/do-react-hooks-replace-r...) - Chris Achard: Can You Replace Redux with React Hooks?](https://dev.to/chrisachard/can-you-replace-redux-with-react-hooks-20gm https://dev.to/chrisachard/can-you-replace-redux-with-react-...)

wilsonrocks 7y ago

I certainly found on one occasion where I felt I had to break the laws of hooks, that it worked much better split into two components.