8 ms·

I have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putt

I have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putting a setInterval inside a useEffect. There's no way to do a normal didMount/willUnmount workflow without other hacks (i.e. useRef) just to set up a simple timer. Maddening! Edit: after writing this I went and read the article. Same scenario I was bitching about lol

littlecranky67 5y ago
People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and react itself works. [0]: https://reactjs.org/docs/hooks-faq.html https://reactjs.org/docs/hooks-faq.html
- toshk 5y ago
  When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me at times when it fires / or not. Too much magic for me. But maybe im getting old :).
  - littlecranky67 5y ago
    Well if you do not want to read the docs, go with vanilla JS ;) Seriously, no matter what you use, read the docs. Arguing that a library should not require you to read the docs is just nonsense - cause any library makes decisions about abstractions for a reason. If you do not want/need those abstractions, do not use the library blindly. It is always the case that you should now and agree with those, that is why you use the library in the first place. So, read the docs, please.
    - furyofantares 5y ago
      The post you're replying to says they've read the docs many times.
      - a2800276 5y ago
        In their defense, they said "read the docs" not "read the comments"... :D
    - anamexis 5y ago
      Ok, but surely it’s a good thing when frameworks are intuitive?
  - mosdl 5y ago
    Same, I just use classes for anything that needs more than a few lines of business logic.
  - dsego 5y ago
    This is my understanding, but I just use hooks, don't know the implementation details. Pure react functions receive props and render output. Each time the component is rendered (basically a function call), it reads the props and spits out some DOM nodes (simplified). But you loose the ability to have lifecycle events. So they invented a mechanism that keeps some hidden state that's tracked for us behind the scenes, and we can then "hook" into that lifecycle state. The main issue is that it's not a native language construct, but a mini-dsl sort of so you need to have this state machine in mind even thought it's implicit and hidden from you. Instead of reading the docs, you might want to search online how to write hooks from scratch. It's one of those concepts that needs to click.
  - stickfigure 5y ago
    I had the opposite experience. I started with classes, and anytime I had to do anything even slightly complicated I had to go running for the docs. The lifecycle methods are byzantine and frequently require not only overriding the method, but checking the values of parameters to determine the proper sequence of operations. In contrast, useEffect() is "exactly what I want" without having to figure out what combination of lifecycle methods to implement. I'll grant you that this could have been done differently - I'm not a fan of the "order of calls represents hidden state" mechanism for hooks. It's possible to imagine a different API for class components that provides ergonomics similar to useEffect() and useState(). But hooks are still an improvement over the old class component API.
  - oaxacaoaxaca 5y ago
    Right there with you. I've been building React apps full time since 2016. I used to convince people to switch to React because of how easy it was to learn and how quick it was to get through the docs. Props, state, setState, done. I've built some really complex frontends with React. But now here I was, struggling with setInterval, ha.
- dataviz1000 5y ago
  I strongly recommend everyone to read A Complete Guide to use Effect[0] blog post by Dan Abramov. He 3 years ago addressed this exact problem and how useEffect solves it. [0] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/
- tshaddox 5y ago
  Also in most of these cases, the "natural" way people would prefer to write code for an interval would likely have very unclear semantics, particularly if the interval delay is coming from somewhere else such that its value can change (like component state or props).
- sakarisson 5y ago
  > The real footgun is people not reading the documentation for the framework they use I would argue that the real footgun with hooks is the case where a `useEffect` call inadvertently gets triggered on each render because one of its dependencies, passed through another hook, changes identity on each render. It can get quite maddening, and in many cases you don't notice it until someone points out the resulting performance issue with your app. The solution, of course, is `useMemo` and `useCallback`, but it's not intuitive and it can be easy to miss from time to time in a large project.
mastersummoner 5y ago
I think I ran into a very similar issue recently too, stale closures right? didMount/willUnmount worked perfectly, but useEffect got screwy very fast, even posted a SO article trying to see the best workaround, nothing great.
robertoandred 5y ago
Sure there is. Set the interval on mount, clear it on unmount: useEffect(() => { const interval = setInterval(() => { // whatever }, 1000) return () => { clearInterval(interval); } }, [])
smrtinsert 5y ago
My favorite accomplishment with react after not using for some time, was to set a conditional timer for app level event using hooks for a set of tiered conditions which should be ignored unless it passed a threshold. Took me at half a week at least and I felt like a god after. Then I realized this was all phenomenal waste of time and I decided my next job was going to be cloud and backend focused. Only in the js world can you realize immediately as soon as your done that it's effectively worthless programming hassle.

littlecranky67 5y ago

People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and react itself works. [0]: https://reactjs.org/docs/hooks-faq.html https://reactjs.org/docs/hooks-faq.html

toshk 5y ago
When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me at times when it fires / or not. Too much magic for me. But maybe im getting old :).
- littlecranky67 5y ago
  Well if you do not want to read the docs, go with vanilla JS ;) Seriously, no matter what you use, read the docs. Arguing that a library should not require you to read the docs is just nonsense - cause any library makes decisions about abstractions for a reason. If you do not want/need those abstractions, do not use the library blindly. It is always the case that you should now and agree with those, that is why you use the library in the first place. So, read the docs, please.
  - furyofantares 5y ago
    The post you're replying to says they've read the docs many times.
    - a2800276 5y ago
      In their defense, they said "read the docs" not "read the comments"... :D
  - anamexis 5y ago
    Ok, but surely it’s a good thing when frameworks are intuitive?
- mosdl 5y ago
  Same, I just use classes for anything that needs more than a few lines of business logic.
- dsego 5y ago
  This is my understanding, but I just use hooks, don't know the implementation details. Pure react functions receive props and render output. Each time the component is rendered (basically a function call), it reads the props and spits out some DOM nodes (simplified). But you loose the ability to have lifecycle events. So they invented a mechanism that keeps some hidden state that's tracked for us behind the scenes, and we can then "hook" into that lifecycle state. The main issue is that it's not a native language construct, but a mini-dsl sort of so you need to have this state machine in mind even thought it's implicit and hidden from you. Instead of reading the docs, you might want to search online how to write hooks from scratch. It's one of those concepts that needs to click.
- stickfigure 5y ago
  I had the opposite experience. I started with classes, and anytime I had to do anything even slightly complicated I had to go running for the docs. The lifecycle methods are byzantine and frequently require not only overriding the method, but checking the values of parameters to determine the proper sequence of operations. In contrast, useEffect() is "exactly what I want" without having to figure out what combination of lifecycle methods to implement. I'll grant you that this could have been done differently - I'm not a fan of the "order of calls represents hidden state" mechanism for hooks. It's possible to imagine a different API for class components that provides ergonomics similar to useEffect() and useState(). But hooks are still an improvement over the old class component API.
- oaxacaoaxaca 5y ago
  Right there with you. I've been building React apps full time since 2016. I used to convince people to switch to React because of how easy it was to learn and how quick it was to get through the docs. Props, state, setState, done. I've built some really complex frontends with React. But now here I was, struggling with setInterval, ha.
dataviz1000 5y ago
I strongly recommend everyone to read A Complete Guide to use Effect[0] blog post by Dan Abramov. He 3 years ago addressed this exact problem and how useEffect solves it. [0] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/
tshaddox 5y ago
Also in most of these cases, the "natural" way people would prefer to write code for an interval would likely have very unclear semantics, particularly if the interval delay is coming from somewhere else such that its value can change (like component state or props).
sakarisson 5y ago
> The real footgun is people not reading the documentation for the framework they use I would argue that the real footgun with hooks is the case where a `useEffect` call inadvertently gets triggered on each render because one of its dependencies, passed through another hook, changes identity on each render. It can get quite maddening, and in many cases you don't notice it until someone points out the resulting performance issue with your app. The solution, of course, is `useMemo` and `useCallback`, but it's not intuitive and it can be easy to miss from time to time in a large project.

mastersummoner 5y ago

I think I ran into a very similar issue recently too, stale closures right? didMount/willUnmount worked perfectly, but useEffect got screwy very fast, even posted a SO article trying to see the best workaround, nothing great.

robertoandred 5y ago

Sure there is. Set the interval on mount, clear it on unmount: useEffect(() => { const interval = setInterval(() => { // whatever }, 1000) return () => { clearInterval(interval); } }, [])

smrtinsert 5y ago

My favorite accomplishment with react after not using for some time, was to set a conditional timer for app level event using hooks for a set of tiered conditions which should be ignored unless it passed a threshold. Took me at half a week at least and I felt like a god after. Then I realized this was all phenomenal waste of time and I decided my next job was going to be cloud and backend focused. Only in the js world can you realize immediately as soon as your done that it's effectively worthless programming hassle.