Hacker News Reader

Comment by fullstackchris | Hacker News Reader

I don't understand the animosity around useEffect. It executes a function based on a list of dependent variables. That's it. Once you understand that, its purpose becomes very clear.

You don't want to rerender? Use useEffect with an empty array! Or don't use any state variables!

You want to show something new to your customers / users without rerendering? Well sorry, that's impossible, regardless of any framework you use and you should go back to UI development 101.

Bottom line: if you write clean code and are aware exactly of what your local state / redux variables are (or whatever state management you are using), you should never have a problem with too many rerenders. I've been writing React for 6+ years now and have NEVER had to reach for useMemo or useCallback.

View on HN

> You want to show something new to your customers / users without rerendering? Well sorry, that's impossible, regardless of any framework you use and you should go back to UI development 101.

When you say “render” are you referring to what React means by “render”, that it will go through the whole virtual DOM cycle? Because it most certainly is possible to avoid that when using pure JavaScript. Why do you say it’s impossible? React’s fundamental problem with performance, and the whole reason people often don’t want to re-render is because React renders everything, then does a big diff on the DOM to compare it to what was rendered before, and then updates the elements that changed. I know a lot of work has been put into making that process fast, but it’s still really expensive compared to the pure JS way of doing it. In CS terminology, updating a button or any other single element went from an O(1) operation with JavaScript to an O(N) operation with React.

To show something new to the user, state must be calculated and pushed either to the DOM or blitted to a canvas.

Not sure I understand your point, can you elaborate?

My point is that updating the state for a single element causes React to compute the state for the whole page, and diff the whole page virtual DOM against the whole page actual DOM, before pushing the update of that single element into the DOM. With pure JavaScript, you can skip all that and directly update a single element. This is often in practice much faster.

I agree, and I'd like an anti-hooks person to explain their thoughts a bit more. My impression is that they believe useEffect inclines devs to cause side-effects in the component, quickly making the logic of a component difficult to follow- for example, a useEffect that sets a state that kicks off another useEffect that sets another state that kicks off another useEffect...

But this problem existed before hooks: old school React devs will remember the days of class-based components with humongous componentDidUpdate methods peppered with calls to this.setState(...) that did the same thing.

My own impression is that hooks offer better lifecycle controls overall, with the side effect (heh..) of handing devs an arsenal of footguns that will inevitably go off if they don't fully understand the hooks or where to use them or how React detects and triggers a re-render. So in a way I agree with the author of the original article here, but in the sense that React devs should probably not use hooks until they understand how re-renders happen and why to avoid that and only then should they be handed one footgun at a time.

My problem with hooks isn't the philosophy but the ergonomics and footguns it creates.

Compare that with Vue composition api, and you can see how idea of hooks can be implemented much better[0]

[0] https://vuejs.org/guide/extras/composition-api-faq.html#comp...

> I've been writing React for 6+ years now and have NEVER had to reach for useMemo or useCallback.

Wha- how?! The moment a useEffect depends on a callback, it needs to be memoized!

Reply on news.ycombinator.com