React traded one set of footguns for another set. This is also after they fudged with the class component lifecycle methods before tossing in the towel on that entire API.

> If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework

yep. They also commandeered the entire use* namespace just so they could get lint to warn when you put a hook outside the start of a function. Hacks on top of hacks.

I have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putting a setInterval inside a useEffect. There's no way to do a normal didMount/willUnmount workflow without other hacks (i.e. useRef) just to set up a simple timer. Maddening!

Edit: after writing this I went and read the article. Same scenario I was bitching about lol

People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and react itself works.

[0]: https://reactjs.org/docs/hooks-faq.html

When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case.

React was easy coming from jQuery, Backbone other frameworks at the time.

With effects, i've read the docs many times. I still don't fully understand how it's supposed to work.

I don't seem to get the feeling / abstract concept behind it and it still surprises me at times when it fires / or not.

Too much magic for me. But maybe im getting old :).

I had the opposite experience. I started with classes, and anytime I had to do anything even slightly complicated I had to go running for the docs. The lifecycle methods are byzantine and frequently require not only overriding the method, but checking the values of parameters to determine the proper sequence of operations.

In contrast, useEffect() is "exactly what I want" without having to figure out what combination of lifecycle methods to implement.

I'll grant you that this could have been done differently - I'm not a fan of the "order of calls represents hidden state" mechanism for hooks. It's possible to imagine a different API for class components that provides ergonomics similar to useEffect() and useState(). But hooks are still an improvement over the old class component API.

This is my understanding, but I just use hooks, don't know the implementation details. Pure react functions receive props and render output. Each time the component is rendered (basically a function call), it reads the props and spits out some DOM nodes (simplified). But you loose the ability to have lifecycle events. So they invented a mechanism that keeps some hidden state that's tracked for us behind the scenes, and we can then "hook" into that lifecycle state.

The main issue is that it's not a native language construct, but a mini-dsl sort of so you need to have this state machine in mind even thought it's implicit and hidden from you.

Instead of reading the docs, you might want to search online how to write hooks from scratch. It's one of those concepts that needs to click.

Well if you do not want to read the docs, go with vanilla JS ;) Seriously, no matter what you use, read the docs. Arguing that a library should not require you to read the docs is just nonsense - cause any library makes decisions about abstractions for a reason. If you do not want/need those abstractions, do not use the library blindly. It is always the case that you should now and agree with those, that is why you use the library in the first place. So, read the docs, please.

The post you're replying to says they've read the docs many times.

In their defense, they said "read the docs" not "read the comments"... :D

Ok, but surely it’s a good thing when frameworks are intuitive?

Right there with you. I've been building React apps full time since 2016. I used to convince people to switch to React because of how easy it was to learn and how quick it was to get through the docs. Props, state, setState, done.

I've built some really complex frontends with React. But now here I was, struggling with setInterval, ha.

Same, I just use classes for anything that needs more than a few lines of business logic.

I strongly recommend everyone to read A Complete Guide to use Effect[0] blog post by Dan Abramov. He 3 years ago addressed this exact problem and how useEffect solves it.

[0] https://overreacted.io/a-complete-guide-to-useeffect/

Also in most of these cases, the "natural" way people would prefer to write code for an interval would likely have very unclear semantics, particularly if the interval delay is coming from somewhere else such that its value can change (like component state or props).

> The real footgun is people not reading the documentation for the framework they use

I would argue that the real footgun with hooks is the case where a `useEffect` call inadvertently gets triggered on each render because one of its dependencies, passed through another hook, changes identity on each render. It can get quite maddening, and in many cases you don't notice it until someone points out the resulting performance issue with your app. The solution, of course, is `useMemo` and `useCallback`, but it's not intuitive and it can be easy to miss from time to time in a large project.

Sure there is. Set the interval on mount, clear it on unmount:

  useEffect(() => {
    const interval = setInterval(() => {
      // whatever
    }, 1000)

    return () => {
      clearInterval(interval);
    }
  }, [])

I think I ran into a very similar issue recently too, stale closures right? didMount/willUnmount worked perfectly, but useEffect got screwy very fast, even posted a SO article trying to see the best workaround, nothing great.

My favorite accomplishment with react after not using for some time, was to set a conditional timer for app level event using hooks for a set of tiered conditions which should be ignored unless it passed a threshold.

Took me at half a week at least and I felt like a god after. Then I realized this was all phenomenal waste of time and I decided my next job was going to be cloud and backend focused. Only in the js world can you realize immediately as soon as your done that it's effectively worthless programming hassle.

React hooks is another attempt to gain ergonomics. The idea is to try to spread the virtual DOM into native effects. In theory the code specifies or declared the effects once and the framework takes care about subscribing/unsubscribing as necessary. But in practice this became so messy that in any complex cases one better stick to classes and explicit subscribe/unsubscribe.

The right way to do that exists in Elm. But I do not think there is a way to translate that into JS without requiring either a lot of boilerplate or very messy code

I agree that hooks "can" be messy but in my experience they are quite useful and nice to maintain. That is if the code is written with maintainability in mind - which applies to any code really.

I've been working on a quite complex React codebase for 5 years now - it's not the biggest but still not so small. I was there on day 1. The team that works on it now full time is ~15 devs + 10-15 doing some minor stuff from time to time.

We've started using hooks about 1 year after they introduced them. Before we were very deep into redux and redux-saga. Now most of our codebase uses only hooks for most of the things we did with redux before - there are still some redux but most major parts are migrated to using hooks and contexts. It is probably the best decision we made after switching to TS. Most of our codebase is still very easy to maintain. Last year I went on a paternity leave for 6 months and I was pleasantly surprised how easy it was to adapt back.

Edit: forgot to write about Elm. I like elm a lot -even though I don't agree with how it's managed-. I even organized a local elm meetup :) But I think while it is very good in theory, it's not too easy to scale especially if you plan on hiring more devs. Also the way effects and data is completely separated from the view is not very ideal for bigger projects. You either end up having to touch too many files for a single feature or have incredibly big files.

For us the problem with hooks is that we have a lot of complex state that can be shown in different components. So global stores are a must. But then bugs in the hooks can be hard to debug. Also lack of forceUpdate for hooks causes to use artificial state counters complicating the code. Basically with external state class components are more straightforward to write and easier to maintenance .

Oh that's jumping the gun. TEA doesn’t compose and you can pretend you don't need components until you do and then you end up with big mess of hard-to-follow spaghetti code. It's not 'bad', and has good use cases but The Elm Architecture is not without flaws.

Elm composes just fine and you can get close to the semantics of components. I wrote this over 3 years ago, have been using it in many projects with no concerns. https://package.elm-lang.org/packages/z5h/component-result/l...

There are other ways to achieve similar. You don't end up with "big mess of hard-to-follow spaghetti code", you might end up with a "large amount of unfamiliar-looking code". Getting better at reading a larger-than-anticipated amount of unfamiliar code takes a bit of practice, then it isn't a problem. And then you have all the benefits of Elm with zero problems.

The actual hard thing about code is managing complexity, and working with "it just works" magic when it doesn't "just work".

I agree Elm has some flaws, and there is an initial up-front time investment which is unsavoury to many.

Yeah? I wrote something to deal with it too (https://github.com/toastal/return-optics) 5.5 years ago. You arguably chose the wrong data as `(model, Cmd msg, Maybe extMsg)` instead of `(model, Cmd msg, List extMsg)` which would give you more flexibility and still functions as a monoid on [] instead of Nothing, but allows multiple messages shrug. I tried this approach more recently and it involved me having to encode all of actions in a massive tree and then I still had issues with certain messages including now having to UUID all elements that that previously I didn't need to think about. It was a mess, but the best I could do with the tools at hand.

If you compare this to Halogen (https://github.com/purescript-halogen/purescript-halogen/blo...) where you still have purity but can set up subscribers and listeners from any component. It's much easier to use and for some components like dialogs, it's much simpler. And this actually isn't the best example because with the latest Halogen, Portals (https://github.com/purescript-halogen/purescript-halogen/pul...) was introduced so you can launch a dialog on the spot instead of even needing to communicate between them at all.

This is my anecdote though. And I've been away from Elm long enough now (around 1.5 years) that I've forgotten all the specifics.

Thanks for qualifying wrong with "arguably". I did explain in the docs that it was a design choice, but I see your valid point. My motive was to simplify calling code and require dealing with the external message. It's had the intended effect so far. I'll read over the halogen stuff.

React would work well as a compiled to metal language. Instead we end up with React on Typescript on ES6 on ES5 on the browser that still only has one language targetable. We're shackled to a rocketship in motion desperately monkey patching the engines.

We can at least eliminate ES5 now that IE is dead.

Hooks triggered my code smell detector so bad that I didn't even bother finishing the tutorial.

That said, I still preferred React.createClass so I guess I'm somewhat off the beaten path when it comes to React.

Back when they were initially released my teammate started rewriting everything in them. Little did he know, if you're not careful with hooks, you can severely damage performance.

My take is that if a feature requires a linter to be properly implemented then it's obviously giving the developer too much rope to hang themselves with.

Also it appears that they were introduced mainly for performance, but for some reason sold as the new "better" way of writing applications.

I actively avoid React and its ecosystem, because I believe there's just too much FOMO and "fashion"(for lack of a better word) in what drives its development and not enough meritocracy.

Read the implementation of Hooks (in the React codebase) if you want a big LOL. They're a slower, partial re-implementation of objects with bizarre custom syntax. In a language that's already so heavily OO that the functions are objects.

>If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges!

Those linter warnings with React hooks show just how much of a disaster it is. All of the "simplicity" that comes with hooks is just complexity that is now completely out of sight, and only appears once the code is run in a linter. That is even worse than having the complexity in the code.

After working with React for years it is something I would not recommend and can only think of limited use cases to use.

You can write really performant software in React, but ergonomic (beyond stockholm syndrome) I would not call it.

It's also difficult to implement quality software engineering principles in a React application such that an application is maintainable, glacable and easy for someone new to a project to pick up.

The flexibility in its toolchain is nice, however

> "glacable"?

Opps, "glanceable"

Yes hooks are not great. They violate too many functional programming rules that the react team pretend to care about.

I still like using them however. I had a few issues when trying to do more abstract code.

I don’t understand why people think react hooks are meant to be ‘functional’.

They are highly, deliberately, emphatically procedural.

The order they are called matters! The time of when they are called matters! The number of times they are called matters! You get a different result from calling the same hook with the same arguments at different times! You get different results if the call site for them is in different places!

They do enable you to do some things in JavaScript that are more easily enabled with higher ordered function stuff in functional languages, but there is nothing ‘functional’ about how hooks work or how they are used.

And that’s okay! ‘Functional’ doesn’t automatically mean ‘better’ and ‘procedural’ doesn’t mean ‘worse’. For what they do, hooks (considered as the entire hooks ecosystem including linting extensions that help enforce the rules as if they were syntax errors) are a very clever extension within JavaScript syntax that let you pull off some very neat separation of concerns in a reactive code model.

‘Functionalness’ has very little to do with whether hooks are good or bad.

> I don’t understand why people think react hooks are meant to be ‘functional’.

Because when function components first came along that's what the whole of React was supposed to be: "functional" UI, using things like redux or mobx for state. Plenty of guides still use that terminology even though React's homepage now uses "declarative".

That said I think they were always misusing the term, I remember this because I used to complain to people that react itself was declarative, not functional, and just gave the option of writing in a functional style.

I'm not sure what happened over there but they completely lost the plot with hooks. And now you're not "correct" or "modern" if you don't use them. They're ... fine, I guess. Most of the time. But not at all in line with the fairly clean and consistent vision of early React.

>"If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges".

I do not want this handled at the framework level though. There are plenty of times in my day-to-day where that linter is wrong. If I were to add one of the dependencies (it's sure I should add) my component would re-render over and over. Sure, one could argue, "well, then you've poorly architected your code"... but THAT is where I feel like the failure occurs. Having to do write my code to please a paradigm. What that means is I only "sorta agree" with the design trade-offs. And much like Ruby on Rails, you either go all in, or spend your days hating the framework.

I do worry that Solid also has these "If you know, you know" edges though. So I'm trading looking at a function and assuming it'll run over and over with, looking at a function and thinking, "how can I make this thing run again when it needs to?" I'm not saying it's wrong, it's just another piece of tacit knowledge one has to learn when adopting a new framework.

Read the hooks FAQ, the linter is not wrong, you are :) https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-f...

Did you see my comment about "yes I could rearch my code but..." The fact that I'm writing in some very specific way to please a linter IS the problem... regardless of whether we tell someone beforehand.

If I know I have a dependency I want to ignore, to achieve a certain result. Then I have a way to achieve a particular data flow. One can _say_, that's wrong but it's a deterministic way to achieve that result. Calling it "wrong" delves into the weirdness of hooks. Love them or hate them, they create patterns which must be learned and mastered. And even then... they can still be confusing. Except for on the internet obviously, here we find people who never have problems with them :)

I like Elm. :)

On the JS/TS planet there's https://cycle.js.org , which comes close.

Looks even better than Solid IMHO.

With Class components it was often easier to create Pure components, or do a shouldcomponent update check to optimize performace. They later introduced memo for functional components.

> If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges.

Isn't the point of static analysis (including linters) that they catch those kind of bugs? Having that little red underline (or console warning) saves a lot of pain.

Hooks have completely changed the way I write React code. It's so much easier to test and reason about. Really the only problem is that the guardrails aren't more heavily enforced.

I don't think complaining about needing a linter makes sense. JSX is already a compiled language, so you have a compile and build step (doubly so if you're also using Typescript). Think of ESLint rules-of-hooks as just a plugin to your compiler that further modifies the syntax of JavaScript to include rules about when and how you can call certain functions.

Hooks are a syntactic element of react code. Calls to them aren't legal inside conditionals or loops.

Full linting support smooths over that rough edge just as effectively as babel handling ?. syntax smooths over its absence in certain JS runtimes.

The idea with hooks is a compiler could generate the dependency array. The flaw isn’t with the hooks paradigm

But those dependencies would be static. This goes beyond that. I won't call hooks flawed, they are suitable for React's model, but looking at what reactivity does is a different sort of thing. It is a subtle difference at first.