Were React hooks a mistake?

Signals and hooks are solving different problems.

React was designed to allow you to think functionally about UI. Your UI should be a pure function of your state. This has always been the goal. All your code runs on every render unless you specifically tell it not to.

Signals are the opposite. A solidJS component runs once, and only the reactive bits ever update. You have to opt into reactivity instead of opting out of it.

The post gives an example of an unintuitive use of hooks, but misses the point. Yes, it's a tricky use case, but the ability to write custom hooks means you need to solve this problem once per codebase at most. The author's "kludgy" solution just needs to be put in a `useTimeout` hook (https://usehooks-ts.com/react-hook/use-timeout). The kludge shouldn't live in the component.

There are some weird cases when you rerender the whole world whenever state changes, but there are plenty of weird cases that it prevents. React's model encourages treating variables immutably and preferring pure functions for modeling your domain. This is hard, because it's not how most JS devs learn to write code before coming to React. But knowing that the whole world is going to rerender gives you tremendous certainty in other areas. Depending on how complex and reactive your UI is, maybe signals would work for you, but if most of what you see on the page is reactive, I'd probably prefer the React model.

One of the promises of using hooks was that you wouldn't have to care about things being recreated every render. Gone were the days of complex update logic in lifecycle methods like `componentWillUpdate()`, `componentWillReceiveProps()`, `componentDidReceiveProps()` etc. Now you use clean, functional components everywhere, even if they needed local state. No kludge, just clean code.

But most of the production functional React code I see is sprinkled so liberally with complex `useCallback()`, `useMemo()` and `useRef()` calls to prevent unnecessary updates that it seems just as bad as before. Worse, sometimes, because the hooks pattern can encourage more indirection. I still find myself thinking all the time about object references in state, cloning vs. mutating, dependency arrays with 5, 6, 7 distinct dependencies.

Honestly, I don't know if it's any better than it used to be. At least the `componentDidReceiveProps()` logic tended to all be in one place.

All of this tricky reasoning about what executed when - and what is closed over vs not - is challenging for most developers. The class version is the most straight forward by a wide margin compared to either React function components or Solid functions. I am happy writing hooks and figuring out the right way to express my effect conditions, but I read a lot of code that gets it wrong, and when I talk to devs they often don’t have as strong a mental model for lexical scope, lifetimes, and closures. Ultimately I think either function API is too subtle for the median developer I’ve worked with.

The best take I've been offered is that the problem with Hooks is that they are kind of a quasi object-oriented solution (more or less it is encapsulating state with a setter/getter) shoe-horned into a quasi-functional render pipeline that demands functional purity at scale (lest your performance falls off a cliff from over-rendering or you end up with odd side effects).

That disconnect is why hooks just don't feel right.

I go back and forth on this - overall, I don't think hooks were a technical mistake (it's a fairly clean way to share code that is not cleanly shared in class components) but... I they accidentally knock a LOT of developers out of the pit of success. Overall - I think they accidentally made React apps a lot more unwieldy.

My sweet spot for React was when it was class based components mixed with purely functional components.

That combo led to all sorts of "happy accidents" in developer productivity. Logic that needed state tended to be clumped into a relatively small number of class based components, developers actively wanted to avoid adding state to new components because they had to write a lot more code to do it.

So you end up with a structure that looks like several small trees in the code: A single class based component managing the state for several pure function components under it. Overall - this was a fairly happy spot to be. State is contained, performance is usually pretty predictable, pure mappings are encouraged.

Hooks... well - they made state too easy again. Now adding state to a new component isn't a 20 line change (conversion to class). It's just dropping a new "useState()/useEffect()" call in near the top. Very easy. So easy you no longer really think about why that might not be such a great idea.

Now you end up with state creeping through the entire component tree. Renders are hard to predict because any parent component might re-render at any point, you're neck deep into useMemo and useCallback to try to prevent all those extra renders from really killing performance. This is not such a happy place to be.

Can those downsides be avoided? Of course. But developers no longer fall into the right path by default. You have to wrangle them there, and that's a huge downside.

I think I am getting old and cynical. These days whenever I read a blog claiming some approach has recently "exploded in popularity" and implying it's the 'ultimate solution' to whatever problem space, I mentally start counting the days until its inevitable replacement with the next fad...

Am I the only one who thought that class-based React components made perfect logical sense and "hooks" are way too magical and confusing? Plus I ran into this exact drawback (trying to access state from within callbacks) on a recent project. I feel like I'm taking crazy pills when I see hooks everywhere.

I miss using React Redux.

I'm a back-end dev primarily and never had a good time writing front-end code. Redux just clicked for me. The model made perfect sense! Events from components get handled, and the state is changed. The state is then re-rendered. Beautiful.

It feels like hooks replaced a lot of what redux was doing, yet I don't have the same sense of reasoning as I did with redux.

But again, I'm mostly a back-end dev.

I have not seen a better client state management than re-frame. https://github.com/day8/re-frame

Notably the author of re-frame has been weary of hooks.

I think that’s for a good reason. The approach in re frame feels like the best way to manage state so far for a react based app. Everything that changes state flows through an event. State can only be observed through subscriptions. Side effects are isolated to their own type of event. Debugging and testing are so straight forward with these concepts.

Redux got close but it has two problems in my mind. Like hooks, it encapsulates for no good reason. Put the state in one thing that you can observe holistically before and after pure events. It also has too much boiler plate.

Slightly off-topic but I'm struggling to understand the choice of that weird looping font the web page uses for keywords in code.

IMHO best-case scenario with React is there's a lot of "you're holding it wrong" in which case we have to ask ourselves, is it that most programmers aren't skilled enough or that the tool is designed wrong? Both are possible but the latter is in general more likely.

I also think there's an issue where react was made to solve Facebook's problems and we're not Facebook.

A bit off-topic: How is any of the code samples intuitive for a beginner to use. I understand and love the reactive principle (and it immense benefit when it comes to sizeable UIs) and high-level react (never coded it) ... but still, the sheer complexity introduced for a simple counter by these 3 evolving snippet.

This is not how I want my grandkids to code software (if the AI overlords let them).

React hooks were a huge mistake because they (along with the huge push by Gaaeron to ditch redux at the same time) disrupted the more declarative styles in React that subjectively relax the mind. Boilerplate code is tedious, but gives the brain a rest from reasoning that many developers actually enjoy. You can really get in the zone wiring up a react/redux app and isolate yourself from re-render logic by focusing on individual stores, reducers, and action logic.

The hooks people came in and said F all that, lets instead create an API that garbles up all the code in one spot, with imperatively nested functions required for more complex use-cases, oh and lets use CONTEXT for state management and just partition items up to deal with re-renders.

They didn't do it on purpose, the react team is highly skilled, but they lacked the wisdom to understand how lower tier or mid-tier developers would use it. I knew plenty of devs that had 3-4 YOE and couldn't grok hooks for years.

Having a good way to compose stateful behaviour in React components is really useful. The alternative is a mess of higher-order components which quickly gets very annoying and tedious. Hooks provide that ability, and they make a lot of cases much easier to write.

Hooks also have some behaviour that makes them harder to understand in certain situations. Closures are quite easy to get wrong, and handling callbacks is quite annoying because they're not stable by default.

I think the timeout example is not ideal, it uses useEffect to handle an event, which is not the way this is supposed to be done and which does lead to various complications. But timeouts are the kind of thing that is much more difficult in hook-based React than it should be. But I don't think this is representative, it's a bit more like a worst case for React for things that should be simple but aren't. You don't write timers all day, you put this in a hook once and write other stuff.

Way too much churn in React. People have products to build, they don't want to re-learn a new way to use React every year.

I think hooks were a mistake.

I think components should have been made pure functions, with state/effects being provided by higher order components (HOCs).

For example:

  Counter = ({count, setCount}) => {
      // pure function here
  }

  StatefulCounter = withState(Counter, {
      count: {
          setCount: 0
      }
  })

If react, and specifically react using functional components, is going to be a full featured web framework, hooks or something like them are necessary to integrate with the browser and the web of 2023.

The 101 parts of functional programming are a very easy pitch. Stateless behavior, testable functions, no surprising side effects from way down the tree. When it gets to 201 stuff - boxing (like useRef) and dispatch (like useState) complexity creeps back in. That complexity is necessary, however, because that's the stuff people actually want to do.

Hooks let react interact with browser audio and video, mapping tools, and other things that are reasons why people want to use web pages. They're complex, but there are limits to how simple a bridge between a functional programming framework and a mostly stateful host system can be.

Reminds me of a story, The Emperor's New Clothes (H.C. Andersen, 1837).

The emperor gets tricked into buying new extraordinary clothes. They are incredibly fancy, but invisible to anyone "who was unfit for his office, or who was unusually stupid".

The emperor didn't see them, but of course he didn't want to admit that. The whole lot of townspeople didn't see them either, but likewise, no one wanted to admit that.

In the end, the emperor goes to town, naked. Everyone praises his new clothes. Until finally a little boy utters: "But he hasn't got anything on!" and the truth unfolds.

https://andersen.sdu.dk/vaerk/hersholt/TheEmperorsNewClothes...

If this was code I'd have to review I'd give the feedback that the wrong information is kept in state.

After start the only thing the setTimeout should do is set the game to be finished and then show the final count to the user. If the code wouldn't have used an alert which definitely is a side effect of a function it gets apparent where the code went outside of the React loop. Not defending that but saying that alert and console.log conflict with React's always re-execute approach and for those cases, as you would have guessed, you can use useEffect and only listen to the finished state to execute your alert.

Throwing a console.log/alert into the direct function body of a component just asks to be spammed by rerenders (assuming the average developer)

React hooks are the best reactive state management for frontend I’ve ever used.

They provide more or less the same functionality as Rxjs, but are 10 times easier to understand.

Yes, they are not perfect, but they solve a very complex problem. It’s the easiest solution I’ve ever seen.

I prefer this, what's it called? observable?

  function createButton() {
    var button = document.createElement("button");
    
    function setClicks(clicks) {
      button.innerText = "This button has been clicked " + clicks + " times";
    }
    
    DB_STATE.get("click", function(err, clicks) {
      if(err) alert(err.message);
      if(clicks == undefined) clicks = "?";
      setClicks(clicks);
    });
    
    DB_STATE.on("click", setClicks);
    
    but.addEventListener("click", function() {
      DB_STATE.do("click");
    });
    
    return button;
  }

Not having heard much about signals my takeaway from this is that they allow you to write functional components assuming the function runs exactly once, thus sidestepping issues with closures etc on updates that cause further runs of the function.

Is that right? If so it's pretty smart I think.

I'm not really a fan of the 'magic' introduced that makes it work via direct DOM manipulation on updates. It seems suspiciously like that's yet another source of mental model confusion that articles will be written about a couple of years from now... but overall it does seem a lot simpler for most usecases.

To me React clicked because it was basically PHP or a template engine, just on the frontend and it rerenders when necessary. You can treat it mostly like that, even if it is more complicated.

Where signals get into trouble (I think) is when the structure of the elements change a lot, and that's when I'd expect bugs in DOM manipulation or state handling to show up. You also need to remember to listen to these signals, otherwise you have something that updates fine under certain circumstances and not others.

During the original hype over hooks, I vividly remember thinking: 'I wonder how long we'll wait before these too are reviled.'

We're getting there.

Only if you weren't writing code for a bigco (imo) - hooks simplified a lot of enormous components to be almost readable

Well, I don't know about hooks being a mistake.

What I do know is that the font choice in those code blocks was DEFINITELY a mistake.

They were not a mistake, people just need to grok them better. You need to embrace functional purity.

I copied this code into a current project and the alerts all had the correct counter.

anything that isn't the garbage OOP with its infinite bloat is progress

“Put another way: class components have a single instance per mounted component, but function components have multiple “instances” — one per render. Hooks just further entrench that constraint. It’s the source of all your problems with them”

I see this a lot, it’s probably the misunderstanding that drives most of the dissatisfaction with hooks.

Having a single instance that exists for the whole lifetime of the mounted component was a major advantage of class components, the major drawback being that you kept losing immutability.

The big advantage of functional components is they give you all that immutability, their drawback is you no longer have a single instance that corresponds to the mounted component’s lifetime, because functions are just executed and then they’re gone (until the next time you execute them).

The way to think about hooks is that React will create a internal virtual instance that does correspond to the lifetime of the mounted component, and it will let you hook into that virtual instance from the function (to store state, effects, refs, etc). The idea was that way, you can have both immutability and single-instance-per-lifetime benefits.

Because React is managing all of these internal virtual instances itself, it can do some nice magic like letting you use a clean top-level “useState” function and it Just Works… because behind the scenes it is pairing up each call to that function with each internal virtual instance (using its order in the call stack, which means the magic fails if hooks are called conditionally, hence the rules of hooks).

That’s fundamentally the concept that lets you work with hooks fearlessly. You no longer had to provision each of your class components with their own instance and make sure they were maintaining it properly, instead your function components could just clock in and clock out and React would take care of making sure they were handed the right instance to work with.

If I had to pinpoint the exact mistake React made with Hooks, it was this: saying you could emulate componentDidMount with useEffect(fn, []). It completely obscures this idea of a virtual instance you’re hooking into. They should have been explicit about the virtual instance model and given developers “useDidMount(fn)” and “useWillUnmount(fn)” hooks, explaining that for each function component you write, React is managing an instance for it behind the scenes and React will make sure it runs the provided mount and unmount functions at the appropriate moments in that instance’s lifetime.

One can imagine a hybrid option, a lightweight class definition (so you could set state in constructor, define DidMount, make refs, etc., in the natural way) that would then return a functional component. That would make the long-lived instance explicit, but I think the ergonomics would unfortunately suck: “render() { return function (props) { return <div/> } }” is hideous, for example.

mods, can we ban these React bashing threads which seem to pop up every other day? another recent thread[0]

I get that react is full of problem and many people have to suffer because of it. But we are not even attempting to change status quo here. This thread merely serves as place to rant. and then go back to same problems. At this point, i have most of the opinions memorized and i am not even a React dev.

PS: if people are really into React/vue/angular rants, then have a monthly thread for it.

[0] https://news.ycombinator.com/item?id=35061672

yes, anything that muddles the stack trace is

yes

I am so happy I don't have to touch front end code for my career

It was like an admission that their idea couldn’t handle many cases and they made a release valve.

There are other approaches like Signals… or Angular… or our totally different approach:

https://qbix.com/platform/guide/tools#designing

There is really nothing wrong with simply having components without unidirectional flow, with being able to simply pass options down to child components.