6 ms·

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 tha

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.

Apotheos 3y ago
What's the new way as of a few months ago? The docs way?
- rkuykendall-com 3y ago
  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.
  - andrewmcwatters 3y ago
    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?
    - deleted 3y ago
      [deleted]
    - c-hendricks 3y ago
      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.
      - deleted 3y ago
        [deleted]
    - ihateolives 3y ago
      > 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.
  - q7xvh97o2pDhNrh 3y ago
    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.
    - dboreham 3y ago
      It turns out much of s/w development is a cult (many cults) with no basis for their teachings.
    - Izkata 3y ago
      > 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.
    - flashback2199 3y ago
      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.
    - bilalq 3y ago
      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.
  - Kiro 3y ago
    Then how do I emulate onMount now?
    - rkuykendall-com 3y ago
      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.
nop_slide 3y ago
What are the clashing philosophies?
- cjauvin 3y ago
  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..
brundolf 3y ago
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)
- tunesmith 3y ago
  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.
- rhaway84773 3y ago
  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 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 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.
  - rimunroe 3y ago
    > 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 https://react.dev/learn/synchronizing-with-effects
rimunroe 3y ago
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.
- quickthrower2 3y ago
  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.
  - rimunroe 3y ago
    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?
  - moritzwarhier 3y ago

Apotheos 3y ago

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

rkuykendall-com 3y ago
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.
- andrewmcwatters 3y ago
  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?
  - deleted 3y ago
    [deleted]
  - c-hendricks 3y ago
    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.
    - deleted 3y ago
      [deleted]
  - ihateolives 3y ago
    > 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.
- q7xvh97o2pDhNrh 3y ago
  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.
  - dboreham 3y ago
    It turns out much of s/w development is a cult (many cults) with no basis for their teachings.
  - Izkata 3y ago
    > 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.
  - flashback2199 3y ago
    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.
  - bilalq 3y ago
    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.
- Kiro 3y ago
  Then how do I emulate onMount now?
  - rkuykendall-com 3y ago
    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.

nop_slide 3y ago

What are the clashing philosophies?

cjauvin 3y ago
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..

brundolf 3y ago

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)

tunesmith 3y ago
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.
rhaway84773 3y ago
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 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 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.
- rimunroe 3y ago
  > 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 https://react.dev/learn/synchronizing-with-effects

rimunroe 3y ago

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.

quickthrower2 3y ago
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.
- rimunroe 3y ago
  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?
- moritzwarhier 3y ago