Hacker News Reader

Comment by tunesmith | Hacker News Reader

I sometimes feel like there are three. The class components way, the hooks way that everyone has been doing it up until a few months ago, and the hooks way that the beta docs say you should do it. Maybe those last two aren't different enough, but the clashing philosophies around useEffect are enough to require massive refactors.

EDIT: I'm referring to how the proper use of useEffects is to almost never use them. They're for side effects, and they're not a tool to just "re-render when these dependencies change". But to do this right, it requires a re-wiring of the mental model of how to do React, at least for many people I've come across.

View on HN

This isn't a recent development. People misusing useEffect just to update state has been a thing in React since they were introduced, even though a close reading of the original hooks docs should have conveyed that that's not what they're for. I think the new docs certainly make it clearer what the correct usage is, so now lots of people are finding out that their mental model isn't quite right.

Some of this predates the introduction of hooks, as much of the useEffect misuse is identical to the way people misused componentDidMount/componentDidUpdate/componentWillUnmount.

I don't think you're right to say that you should almost never use them. You should use them for doing the things which they're designed for, like attaching event listeners or dealing with timers (neither of which are that unusual in my experience). But like I said, they've never been a tool for dealing with rerenders, and the React team has been trying to explain this to people for ages. The original docs did explain this, but it was less clear than the new ones.

Exactly, this is the same as saying Redux has two methodologies, the "setter system" and the "event system"; since it wasn't that well documented initially doesn't mean that the setter way was ever recommended (it's not). In fact if you watched the Flux youtube talk, something highly recommended to learn the philosophy behind Redux, it was pretty clear.

Edit: here's the video (from 10:20) https://www.youtube.com/watch?v=nYkdrAPrdcw

As a misuser on hobby projects, what is the best way to do an initial API call once the main component has mounted?

I was using useEffect, with the deps being the things sent to the query.

For what it's worth, "the deps being the things sent to the query" is fundamentally correct. What were you doing wrong before and what are you doing now? There are alternatives to making queries with useEffect which can result in a better user experience. Were you alluding to those?

One of the sources of confusion I see the most around effects is that people still think of them in terms of components mounting and unmounting. However, effects only care about running, cleaning up, and maybe needing to run again. I can't think of a case when they'd need to know about the component's mount/unmount behavior.

For effects, the main things to consider are:

• Can this effect be fired unconditionally, and if not, what could change in the system to make its result inconsistent/outdated with the new state of the system?

• What cleanup does this effect need?

It seems mostly expected to have a framework or library in place that takes care of data fetching for the root component.

The new docs emphasize this, I guess mostly to make users think twice about building their own hook and to make it easy to move initial data fetching to the server.

Frameworks include next.js, remix or vite-plugin-ssr (the last one is maybe an outlier, as it deems itself a library).

Often fetching is tied to routing, which makes sense.

If routing is not needed, AFAIK the go-to solutions right now are react-query or SWR.

https://swr.vercel.app/

react-query has a nice comparison table for data fetching libraries:

https://tanstack.com/query/v4/docs/react/comparison

If routing only takes place on the client, react-router also includes data fetching features:

https://reactrouter.com/en/main/guides/data-libs

I don't know how well react-router fits with SSR.

If none of that fits and the requirements are either very simple or very custom, it should still be possible to manually pass props to the root component.

Looking this up in the docs, the big caveat of this unconventional approach is that props would not be reactive, the root component would have to be manually re-rendered:

https://react.dev/reference/react-dom/client/createRoot#upda...

I think the "new way" was always the intent. If the past norm is different, it was probably a communication issue (which the beta docs are trying to address)

I'd agree.

I haven't tried asking GPT4 a bunch of react questions yet. I wonder if its advice is generally in accordance with the "new way", given the training data cutoff date.

It’s very clear useEffect was created with a certain purpose and then the React folks realized that was a terrible use of it and changed the purpose of useEffect.

And this would have been fine if they had been upfront about how they were wrong about useEffect and how now this is the correct way to do it. But instead, they’ve at best kept silent about this transition, and a lot of people strongly attached to React have decided to gaslight everyone else about useEffect (I’m a huge React fan… it’s my default UI library but that doesn’t mean I’m ok with gaslighting over transparency).

And the easiest way to prove this is to compare the docs.

Original: https://legacy.reactjs.org/docs/hooks-effect.html

> The Effect Hook lets you perform side effects in function components:

New:

https://react.dev/reference/react/useEffect

> useEffect is a React Hook that lets you synchronize a component with an external system.

Synchronizing with an external system is completely different behavior from performing side effects. And we know the original intention was to perform side effects and not sync with external systems because the name of the hook is useEffect and not useSyncExternal.

Unless the React team always had the new intention but deliberately decided to mislead everyone through the original documentation and by misnaming the hook, but I don’t think even the biggest React hater thinks so poorly of them, and I’m a fan.

> It’s very clear useEffect was created with a certain purpose and then the React folks realized that was a terrible use of it and changed the purpose of useEffect.

I've compared the docs, and I don't think that's clear at all. They definitely refined their messaging, but the legacy docs show the same sorts of examples that are either shown in the new docs or described[1], such as subscribing to an event system or updating a bit of non-React UI. Could you give some sort of example usage that they encouraged before but don't now?

[1] https://react.dev/learn/synchronizing-with-effects

I mean, I would argue "synchronizing with an external system" is almost synonymous with "causing side-effects [on render/state change]". Maybe "synchronizing" is a narrower subset of "effects", but I think that's less of a change of the intent and more of a refinement

And I do think the team has been refining this conceptual territory as they go. React is a pretty unique programming paradigm at this point, there's lots of uncharted territory. Following Dan Abramov on Twitter, he works through concepts out loud, having new realizations about how the primitives they've created fit together, what their implications are, metaphors for thinking about them, in real-time. I think they've got a very clear direction at this point, but they haven't turned over every stone along the way yet.

> Synchronizing with an external system is completely different behavior from performing side effects.

No, synchronizing with an external system is exactly performing side effects. It is a change in document focus from a description that focuses on what it does to one that focuses on the purpose for which it does it, but all synchronization with an external system is side effects and the vast majority of side effects that aren’t incidental to imperative program structure (which functional components avoid) is syncronizing with an external system.

What's the new way as of a few months ago? The docs way?

They may be referring to React 18 + Strict Mode meaning all useEffects can be called as many times as React wants. People before were writing code where useEffect on [] worked like onMount and was only called once.

What's so infuriating about that is the documentation basically told people, hey instead of doing this, use useEffect the way you were using these methods.

So are the users wrong, or did you screw up?

If you're ignoring dependencies that should be on a call to `useEffect`, you're just making room for bugs.

If you're not properly tearing down what you're doing in an effect, you're just making room for bugs.

These have always been true of useEffect.

> So are the users wrong, or did you screw up?

When you have to rewrite the documentation to basically tell the world "you're holding it wrong" then it says a lot about the thought that has (not) gone into designing the feature.

And that's why I think I'm done with React for now. It just does not spark joy.

The entire hooks "thing" felt like a case of the library authors being too clever.

Having components with lifecycle methods called at known times by the framework is a perfectly straightforward mental model. It's worked just fine since the beginning of time. iOS still uses it.

I remember investing hours (and days and weeks) migrating old code to the "new way" or trying to get some simple thing "working with hooks." Other than being able to share in the authors' feeling of smugness over the unnecessarily-convoluted mental model when we finally got it all working, I genuinely can't recall any value we got out of the whole investment.

It turns out much of s/w development is a cult (many cults) with no basis for their teachings.

> Having components with lifecycle methods called at known times by the framework is a perfectly straightforward mental model. It's worked just fine since the beginning of time. iOS still uses it.

Android, too.

I agree. Hooks felt to me like an attempt to go all-in on functional programming when components are perhaps easier for many people to think about as classes due to the unavoidable need to have state in the component. It seemed like an attempt at purism that, instead of making things simpler, made them, at least cognitively, a bit more complicated due to the irreducible complexity of state.

My experience has been the opposite. With hooks, it's now possible to decompose a concern and modularize it in full. Having logic for dealing with a concern spread over willMount/didMount/shouldUpdate/willUnmount was a total mess. It's bad enough with one concern, but if a component has 3 or 4 concerns that span across the lifecycle, it quickly became unwieldy. And for all the complains about people using `useEffect` wrong, I saw just as many people using setState calls in lifecycle methods and crazy things happening in mapStateToProps of class components.

In the end, hooks have greatly simplified things for me.

Then how do I emulate onMount now?

You have to use a useRef then inside your useEffect of [] you check if it is false and it it is you set it to true then run your code.

If anyone reads this and I am wrong please comment, but from what I can see that's the only solution.

What are the clashing philosophies?

I'm not sure about the clashing philosophies, but useEffect is certainly a "nexus of difficulties" about learning and using React (with hooks), in terms of the mental model it requires, knowledge of not-so-obvious JS concepts like closures, etc..

Reply on news.ycombinator.com