<story><title>You might not need an effect</title><url>https://react.dev/learn/you-might-not-need-an-effect</url></story><parent_chain><item><author>billllll</author><text>IMO if you need a long doc like this pointing out the sharp edges, then I think you&amp;#x27;ve done a poor job in designing the framework.&lt;p&gt;I love the terseness, reusability, and typing of React hooks, but hooks have too many weird edge cases (this article, dependency list, order of hooks, etc) versus class components, whose design was simple and elegant.&lt;p&gt;I&amp;#x27;m just an old man yelling at clouds though, the terseness of stateful components defined in a function, plus simple typing with TS (no defining proptypes) is too appealing to me personally. Maybe I&amp;#x27;ll check out Solid next time, which seems to have less weird edge cases.</text></item></parent_chain><comment><author>cbovis</author><text>I actually disagree here pretty heavily and think that this doc is due to the bar for competent developers going down in recent years (due to the rise in necessity for more developers of course). There&amp;#x27;s almost an expectation that powerful tooling should be dumbed down.&lt;p&gt;The entire doc is written around two common problems:&lt;p&gt;* You don’t need Effects to transform data for rendering
* You don’t need Effects to handle user events&lt;p&gt;Both of these problems do not occur if you take the time to understand the tooling React gives you. The events point should be a given, that&amp;#x27;s just React 101 (and yet they have to spell it out to people...).&lt;p&gt;You don&amp;#x27;t end up using useEffect to transform props&amp;#x2F;state and generate new state if you understand that those things are just variables and you can instantiate new variables using them inside the scope of the component function.&lt;p&gt;&amp;quot;But that&amp;#x27;s inefficient because of how re-rendering works&amp;quot;.&lt;p&gt;Great, you understand how re-rendering works but haven&amp;#x27;t gotten familiar with the useMemo hook. Come back when you&amp;#x27;ve gotten familiar with the primitives available to you in React and how they can all work together in different ways, there&amp;#x27;s not that many of them!&lt;p&gt;This doc reads to me like a DIY store publishing an article about how you shouldn&amp;#x27;t hammer in screws even if it kinda seems like you could if you didn&amp;#x27;t take the time to understand hammers, screws, and nails. It&amp;#x27;s sad that it needs to exist but that&amp;#x27;s the current state of engineering.</text></comment>
<story><title>You might not need an effect</title><url>https://react.dev/learn/you-might-not-need-an-effect</url></story><parent_chain><item><author>billllll</author><text>IMO if you need a long doc like this pointing out the sharp edges, then I think you&amp;#x27;ve done a poor job in designing the framework.&lt;p&gt;I love the terseness, reusability, and typing of React hooks, but hooks have too many weird edge cases (this article, dependency list, order of hooks, etc) versus class components, whose design was simple and elegant.&lt;p&gt;I&amp;#x27;m just an old man yelling at clouds though, the terseness of stateful components defined in a function, plus simple typing with TS (no defining proptypes) is too appealing to me personally. Maybe I&amp;#x27;ll check out Solid next time, which seems to have less weird edge cases.</text></item></parent_chain><comment><author>davedx</author><text>No you&amp;#x27;re right, I completely agree with you. It&amp;#x27;s also very telling that there&amp;#x27;s also this very long article about useEffect dependencies: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;react.dev&amp;#x2F;learn&amp;#x2F;removing-effect-dependencies&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;react.dev&amp;#x2F;learn&amp;#x2F;removing-effect-dependencies&lt;/a&gt;&lt;p&gt;useEffect and dependencies are the worst part of React at the moment.&lt;p&gt;The reason is, you &lt;i&gt;do&lt;/i&gt; need to use effects, &lt;i&gt;everywhere in your code, constantly&lt;/i&gt;. And dependencies, and the linter rule that goes with them, are nasty ergonomics, and hard to reason about.&lt;p&gt;The article I linked does explain it all quite well, and most devs I work with do understand the dependencies rules, but the rule still needs to be disabled often. Why?&lt;p&gt;Often the lint errors really are just wrong. Just like ChatGPT is often simply just wrong, no ifs or buts. For example: you have a callback function declared as an expression, that the useEffect hook calls. The linter will say &amp;quot;oh this is an expression, therefore it needs to be declared as a dependency&amp;quot;. But it doesn&amp;#x27;t, because &lt;i&gt;looking at the code as a human, you can immediately see the function never changes&lt;/i&gt;.&lt;p&gt;If you follow the linter, you will inevitably end up going down a destructive and unnecessary refactoring. You&amp;#x27;ll end up with unnecessary `useCallbacks` sprinkled everywhere that hurt readability for nothing. Often, you&amp;#x27;ll have to refactor the dependencies out of the component entirely, splitting one cohesive component into two, &lt;i&gt;just to satisfy the linter&lt;/i&gt; out of an abundance of caution.&lt;p&gt;Junior devs will be confused. Senior devs will be frustrated. Every react codebase I&amp;#x27;ve worked on has gagged this linter warning.&lt;p&gt;So how &lt;i&gt;should&lt;/i&gt; this work?&lt;p&gt;It shouldn&amp;#x27;t be a a linter error in the first place. Linters should be used to enforce &lt;i&gt;coding standards&lt;/i&gt;, not fix &lt;i&gt;application bugs&lt;/i&gt;. I feel very strongly on this.</text></comment>