Hacker News Reader

Comment by littlecranky67 | Hacker News Reader

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

View on HN

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 :).

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.

The post you're replying to says they've read the docs many times.

In their defense, they said "read the docs" not "read the comments"... :D

Ok, but surely it’s a good thing when frameworks are intuitive?

Same, I just use classes for anything that needs more than a few lines of business logic.

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.

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.

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.

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/

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).

> 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.

Reply on news.ycombinator.com