7 ms·

> Effects are an escape hatch from the React paradigm Hooks are overused in general. But I really disagree with this sentiment. Its useEffect and useLayoutEffe

• robertoandred 4y ago
  Or maybe you shouldn’t be thinking in terms of a “component lifecycle”.
  • lloydatkinson 4y ago
    Exactly - OP is perpetuating bad explanations. https://epicreact.dev/myths-about-useeffect/#:~:text=Here%27s%20the%20crux%20of%20the%20issue%3A%20useEffect%20is,the%20dogId%20changes%2C%20fetch%20the%20new%20dog%27s%20information.%22 https://epicreact.dev/myths-about-useeffect/#:~:text=Here%27...
    • Rapzid 4y ago
      That's bullshit; useEffect is a lifecycle hook. From the documentation for the useEffect SETUP parameter: > setup: The function with your Effect’s logic. Your setup function may also optionally return a cleanup function. When your component is first added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. After your component is removed from the DOM, React will run your cleanup function one last time.
      • dgb23 4y ago
        It absolutely is. But the article and the comments above mention that it’s more useful to have the mental model of synchronizing side effects with state. It’s good advice, because it addresses a major stumbling block people struggle with. After that the code and the way useEffect is used becomes simpler.
        • Rapzid 4y ago
          From the linked article in this thread: > Here's the crux of the issue: useEffect is not a lifecycle hook. That doesn't leave much room for ambiguity; seems like a definitive statement. Many don't see any nuance here and then go around blasting people for saying useEffect is a lifecycle hook because they read on some blog the exact opposite. But anyway, what is a lifecycle hook if not a way to synchronize two systems... ( ͡° ͜ʖ ͡°)
    • ZephyrBlu 4y ago
      The amount of groupthink from React influencers is a big reason why I don’t interact with the community. Posts like this are almost always insufferable.
      • robertoandred 4y ago
        It’s not groupthink, it’s how the library was designed. What’s wrong with understanding the tools you’re using?
        • ZephyrBlu 4y ago
          Lifecycle methods are a valid use case for hooks, yet that use case is constantly bashed (E.g. in this post). There is a very specific way of doing React that influencers and sometimes the React core team push very, very strongly. Sometimes it's justified, but usually I find that it's personal preference being pushed as fact.
  • the_gipsy 4y ago
    How do you handle route changes and data fetching, then? Back to Redux?
    • MrPatan 4y ago
      Never left
      • notpachet 4y ago
        Same boat. It's tiring watching other React devs tie themselves in knots over component lifecycle (either via hooks or class lifecycle methods) when the actual solution is to use neither.
      • yamtaddle 4y ago
        It's downright pleasant, with typescript. All the "waaaah boilerplate" stuff goes away. It's very simple (not even hard to reimplement, in a pinch). Truly does work well with non-React codebases, so if you build your business logic or at least your client-code around it, it's portable. I stopped being a React fan with hooks, but remain a fan of Redux.
    • robertoandred 4y ago
      Those are results from a change in state, nothing to do with whether a component has appeared.
      • the_gipsy 4y ago
        You either have some world state, like redux, or you have react components with hooks. With hooks, those have everything to do with the component's lifecycle. Hooks are included with react, world state management is not.
        • robertoandred 4y ago
          What? You still use hooks with Redux. And you could consider React's Context API as world state management if you really wanted to. And these still aren't intrinsically tied to a component lifecycle.
• kqr 4y ago
  Counterpoint: I'm not a junior dev in general, but a couple of years ago I did my first project involving React. I came back to it a year later and was able to refactor away much hook usage and make components pure. It greatly simplified the codebase and I wish the documentation would have been more insistent on this back when I used it, so I didn't have to earn the experience on my own. I guess the redeeming point is that hook usage is usually easy to refactor out, unless it's permeated your architecture somehow.
  • Rapzid 4y ago
    I agree with everything your saying I just disagree with the communication; well and I believe the line I quoted to be utter bollocks. Dealt with projects that had evolved(devolved?) into hook monstrosities. 20-30 hooks in god components each with n-layers of "custom" hooks each permeated with useEffects and useStates chaining off each other causing a rats nest of render loops and maddening re-render puzzles.. It's awful. I'm anti-hook in general and I use them very sparingly. But they, the effect hooks, are integral to React and need to be used to build the vast majority of anything interesting. People will need to use them or use something written by somebody else that used them. To me that's not an "escape hatch" but fundamental to the libraries usefulness.
    • kqr 4y ago
      I think we agree on all points, then. It's difficult to communicate this to beginners in a way that paints an accurate picture. Laud it too highly and it gets overused, downplay it and you fail to communicate a core strength.
    • robertoandred 4y ago
      You know what they say about blaming tools…
  • ihateolives 4y ago
    > I guess the redeeming point is that hook usage is usually easy to refactor out Yes, but now imagine that you could've done it more or less correct in the first try. Refactors happen, but needing the refactor after it took 2 years for best practices to sink in? I don't think it's an endorsment for the hooks. I refactored my old React app from classes to hooks when hooks became fashionable. Few years later I'm still sure that it's a mess and I've used hooks wrong. Am I itching to refactor again? No way. I let it rot some more, perhaps React will take another sharp turn and I'll save myself time doing it twice.
• strken 4y ago
  Calling things an "escape hatch" (not used in normal operation) when they're more like an airlock (used during normal operation to access a dangerous area) is an irritating language choice.
  • pcthrowaway 4y ago
    Beautifully put, they really are more of an airlock
• the_gipsy 4y ago
  Yes! It helps no one. I think that some authors are just infatuated with FP and can't get over the fact that only the most trivial widget is pure in React.
• ricardobayes 4y ago
  True, this is some really unfortunate wording. Since functional components don't have lifecycle methods anymore, relying on useEffects is pretty much the only way to subscribe to a prop change and render/handle its change. Now according to the new docs, advocating to go "local variables" way feels a bit non-React to me, actually.
  • MrPatan 4y ago
    What do you mean? When props change the component re-renders, doesn't it?
    • ricardobayes 4y ago
      No, it doesn't, a component re-renders when its state changes or its parent re-renders. https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/#standard-render-behavior https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
      • MrPatan 4y ago
        The article you link says that a component will rerender when its parent rerenders or state changes. It doesn't say anything about the props changing. If you read this sentence "In normal rendering, React does not care whether "props changed" - it will render child components unconditionally just because the parent rendered!" and understood that react doesn't re-render a component when its props change, well, I read that sentence in a different way.
• dgb23 4y ago
  The wording is unfortunate as I said in another discussion. useEffect is not an escape hatch, it’s a fundamental building block. The point of articles like these is that people use useEffect when they don’t need them. So it’s robust advice in that regard! But you’re always going to use it, directly or indirectly. For example if you’re doing anything interesting with your layout that CSS can’t exprees, which is fairly often, you’re going to need useEffect in order to read the DOM and calculate your layout.
• bakugo 4y ago
  > I'm really just put off by the React documentation in general. It feels like it's aimed at junior devs working on FE assembly lines and they want to keep the blinders on them. "Pay no attention to the man behind the curtain!". Is this a problem specific to the documentation, or does it apply to React in general (or at least functional components)? Because I feel like it's the latter.
• brundolf 4y ago
  > hooks are THE mechanism they CHOSE to expose component life cycle Yes, and component lifecycle itself is an escape-hatch (or airlock, or whatever). > Function component React would be useless without these hooks; the DOM is an external system! It is an external system, but most fundamental idea of React is that you don't have to write your own effects or lifecycle logic for updating the DOM (the great majority of the time). That's the whole point. The way React lets you update the DOM without using a side-effects programming model most of the time is the reason people use it. Instead of writing side-effects toward the DOM, you write a unidirectional flow of values derived from other values which bottoms-out in DOM (which React then "affects" for you). Custom effects are (mostly) for the situations where you're updating an external system that isn't the DOM. The biggest problems in my experience come when effects become a part of the core domain logic. That's where things get really hard to follow, and that's the most important thing to discourage. Effects should be reserved for the boundary between the app and the outside world (minus normal DOM updates).
  • Mavvie 4y ago
    I agree completely. And that's what I liked about this article: it taught me what effects aren't for. I had been using most of the anti patterns in the article (especially using effects to sync props and state with each other), and it showed me a better way to do all these things.