Hacker News Reader

Comment by codeptualize | Hacker News Reader

Why are so many comments about class components, I thought we ended that debate 3 years ago?

Hooks are better because they allow you to reuse component logic, impossible with class components. They solve all the issues and gotcha's of HOC's.

Don't compare class components with hooks, compare HOC's with hooks.

The best way to grow appreciation for hooks is to try wrapping many HOC's and deal with conflicting props and "innerRefs". People seem to very easily forget the horrors of the old.

Also lets be real, hooks aren't that bad. Yes dependencies arrays and useEffect take some getting used to, but I rarely get into situations where I actually get into questionable territory. Use react-query/swr for fetching, use Zustand (or whatever) for state, and you cut out 95% of the problems.

Anyway, the new docs are great, well done, nice work!

View on HN

> impossible with class components

I'm not sure thats really true. In a different world, the react constructor functions would have access to `this.useState` and `this.useEffect` and then you could extract any logic you like by dispatching `yourFunction(this)`. HOC are not the only alternative design.

Hooks really push at the boundary of the language and I'm not sure they're an optimal path once you actually start dealing with state.

Access to this.setState would be horrible, imagine the conflicts. You need separate state, and then you sort of have hooks again.

see https://news.ycombinator.com/item?id=35192312

> Hooks really push at the boundary of the language and I'm not sure they're an optimal path once you actually start dealing with state.

How do they push at the boundary? I feel like so many people talk about them being magical, but I don't see how they're any different than any other effectful function call. Is the idea of tracking call order that exotic?

This is a very simplified example of how hooks work under the hood:

  let hookStates = [];
  let currentHookId = 0;
  let firstRun = true;

  function endRun() {
    firstRun = false;
    currentHookId = 0;
  }

  function useState(initialValue) {
    const hookId = currentHookId++;
    if (firstRun) {
      hookStates[hookId] = initialValue;
    }

    function setter(nextState) {
      hookStates[hookId] = nextState;
    }
    return [hookStates[hookId], setter]
  }

  let actions;

  function run() {
    const [a, setA] = useState(1);
    const [b, setB] = useState(2);
    
    // this is done because we're not setting up event handling
    // and we need some way to trigger external updates
    actions = {setA, setB}
    endRun();
    return a + b;
  }

  function assert(received, expected) {
    if (received !== expected) {
      let error = new Error(`Expected ${expected}, but received ${received}`);
      error.name = 'AssertionError'
      throw error;
    }
  }

  assert(run(), 3);

  actions.setA(3);
  assert(run(), 5);

  actions.setB(5);
  assert(run(), 8);

  actions.setA(1)
  actions.setB(-1)
  assert(run(), 0);

Obviously this example doesn't include tracking more than one component, but as far as I know hook state gets tracked pretty much the same as the state on class component instances.

I could understand thinking they're magical if you were under the impression you were the one calling the component functions rather than React, but I think my impression was always that it was still React's job to call the function component (otherwise, createElement seems like a waste). They might have at one point said that it was okay to do that in tests, but I'm not sure about that, and it would have been out the door the moment function components started supporting refs.

It really IS weird to reason about.

`useEffect(f, [])` runs on every render, but only installs the effect once. The other times its not installed. That means standard language facilities such as *closure capture* don't quite work as expected unless you pass them in that list `[]` too

Its not impossible to get used to it, but thinking in hooks is profoundly different than thinking with normal javascript.

I think the original design wanted so badly for state to fully live outside of React, but unfortunately, the information about what components are currently active on the screen is very relevant for what the state should be doing. As such, I think that approach just doesn't work no matter how much we'd like it to work.

I never said they weren't weird to reason about. Side effects are hard to reason about. I was responding to the claim that hooks "push the boundaries of the language". Closures work exactly the same as they always do, but they're also something a lot of people struggle with and always have. This is all entirely normal JavaScript, but that doesn't mean it's going to be easy for people. Class components were incredibly easy to introduce subtle bugs in, especially because of the abilities to do things like define your own non-idempotent constructor or doing things like assigning to and reading from instance properties (refs are like this too, but I've seen much jankier code around class instances than the--already considerable amount--I've seen with refs).

Hooks make you run into those potential bugs head-first, and that's always seemed to me like what a large part of the "hooks are hard to reason about" complaints stem from. The other parts are people who expect functions to be invoked in a different way than they are. I don't really know what to tell those people beyond asking them if they've ever seen code calling a component directly.

> Closures work exactly the same as they always do, but they're also something a lot of people struggle with and always have.

Its not normal for a render function to run all the time but the closures mentioned in it to be completely ignored. Thats completely the opposite of how most other APIs work in the language. Usually, a (constructor) function runs once, and the closures returned by it may get run multiple times. Completely ignoring the passed closures to hooks in many/most cases is something very specific to React.

> Its not normal for a render function to run all the time but the closures mentioned in it to be completely ignored. Thats completely the opposite of how most other APIs work in the language. Usually, a (constructor) function runs once, and the closures returned by it may get run multiple times.

React function components are not constructor functions though, so I don't see how those are relevant. Bringing up the expectation that constructors "only run once" in the context of how hooks are hard to reason about seems strange though, as class component constructor functions have to be written in a way where they can potentially run multiple times. I think that's been a requirement for the entire time React has supported JavaScript classes.

What do you mean by "closures returned by a constructor function"? Do you mean the instance and its associated methods? If so, yes, running a constructor obviously produces one instance[1], which is true in React too. But you're never invoking that constructor yourself--and you never should have been doing that with React in the first place--so why would that matter?

Also, I'm confused, can you point at a comparable API to a React function component in the JavaScript language?

[1] well, sort of. Constructors can return any arbitrary object, so the following works

  class Foo {
    constructor(n) {
      return new Number(n);
    }
  }
  let foo = new Foo(1);
  foo instanceof Foo; // false
  foo instanceof Number; // true

> React function components are not constructor functions though, so I don't see how those are relevant

I'm giving an example of whats a normal use case of closures. Running a single function once that creates closures that run zero, one, or multiple times is "normal". Running a single function multiple times that creates closures that run one time and get ignored all other calls of the function is not.

> Running a single function multiple times that creates closures that run one time and get ignored all other calls of the function is not.

This exactly describes a leading-edge debounce function, which I was asked in multiple interviews early in my career to implement on a whiteboard. I'll admit that "problems people feel like giving to junior devs" isn't a great method of measuring whether or not something is simple, but I think it is indicative of how widely that sort of thing is expected to be understood. It also exactly describes any sort of request framework where request responses are cached after the first call and the result is returned without a network hit in subsequent calls.

I would typically save the result of calling debounce (once), then call that, rather than calling debounce over and over on the same inline function (hooks style).

My debounce implementation would *not* be trying to catter to some API that looks like this:

    render() {
      debounce(() => {
        justCallCodeHere(); moreLines();
      })

      debounce(() => {
        anotherFunction(); moreLines();
      })
    }

but more something like this

  constructor() {
    // called only once
    this.debouncedFn1 = debounce(() => { justCallCodeHere(); moreLines(); })
    this.debouncedFn2 = debounce(() => { anotherFunction(); moreLines(); })
  }

  render() {
    // use the created debounced functions
    this.debouncedFn1()
    this.debouncedFn2()
  }

How would you implement the first version without having access to react hooks? Keep in mind that in every call to debounce, the function object you get as an argument is unique because unique closures get created on every call of render().

I hope that illustrates the key weirdness aspect of hooks.

Yes, that's true in this case, but it's not unusual to have something which uniquely identifies a debounced/memoized/cached function though, so that subsequent calls look it up against a registry and avoid repeated computation. In the context of requests, that's usually the URL itself (or some combination of the URL and some parameters). This sort of registry is basically exactly what a component instance serves as is in the context of hooks.

I guess it’s because whilst hooks improve on some aspects, they are quite counter intuitive and very easy to use incorrectly. I don’t think hooks is the final answer to side effects and state in react.

I remember a while ago, if you were to mention HOC wrapper hell in React community, most folks would jump to defend it.

Eventually, React team accepted that it is a problem, and presented hooks as a solution. The very same people who would defend wrapper hell yesterday, would start crapping on it today.

I think you're right that hooks are flawed and not the final answer, but the community won't accept it until "React gods" say so. It would be quite funny if React team eventually decides to go compiler way (a la Svelte) and all the people grasping for reasons to hate Svelte would have to change their opinions again.

React is already looking to use a compiler, but for memoization rather than fully removing the VDOM.

Totally agree.

The ultimate solution (imo) will come from the functional programming world and it will be a component monad, just it won’t look like that to the end user. It will probably leverage function-star in JS. It will enable unit testing of all component interactions and everyone will say it’s the best thing since sliced bread. Clojure devs will look on wondering why it took so long. Just my hunch!

> Hooks are better because they allow you to reuse component logic, impossible with class components

I've heard this said before, but I don't understand. Could you give an example of component logic that can't be reused under class components?

Sure! It's generally about "stateful logic". Basically logic that relies on state and/or the lifecycle methods (componentDidMount, componentDidUpdate, etc) as with classes those are only available as part of a component.

You can "sort of" reuse component logic with classes, the most common way is by using Higher order components (see https://legacy.reactjs.org/docs/higher-order- components.html).

The example in that article is pretty good: Subscribing to some external data source. That requires on mount, state, and on unmount.

Using HOC's is not actually reusing logic though, it's creating more components and wrapping them to compose the logic. It's a workaround.

HOC's have a bunch of downsides, imo the most obvious one is the props; you need to pass the previous props, and merge in the new ones. That can create conflicts. Another typical one is refs. You need to be very meticulous about structure and how you compose and order your HOC's to make sure it all works.

In hooks you can define this stateful logic truly disconnected from a component, resolving a lot of the issues of HOC's as you can just call a bunch of functions without impacting the render tree. The "plumbing" is much simpler.

Hope that is sort of clear, but let me know if I should clarify any of this.

I appreciate the effort, but it's a bit over my head with respect to react stuff.

For instance, I'm not sure what's meant by needing to merge props. I was under the impression that you could pass a subset of properties as an argument to setState, and all else would remain untouched.

I wasn't thinking of using HOC's. I've done a bit of react, but never touched them. I'm just thinking of reusing logic using the same techniques I use to reuse logic in code. React famously asserts "it's just javascript". Javascript provides a way of reusing logic, namely functions. If I have two class components that have the same logic in them, I'm imagining just putting that code in a function. This is not a sophisticated argument. There might be some reason that wouldn't work, but I don't know what it is.

> React famously asserts "it's just javascript".

I think that specifically deals with when using JSX, compared to other templating systems.

With merge props I mean passing down the local state to the next component. If you see the react article I linked it’s the injectedProps.

I think this might be quite common, if you haven’t experienced HOC hell I can understand the confusion why hooks are necessary.

In terms of putting it in a function: there is only one state object per component, you could pass setState around, but you can imagine what would happen if many functions call it. It’s also a lot more effort on the implementation as you would have to basically pass state, and call do some sort of update in the lifecycle methods. It would probably work for one function, but with many it will get problematic. You would almost have to write your own pseudo hooks framework to make this work in a decent way.

You shouldn't pass properties to setState. That's a very non-reactive kind of thing. Just use the properties directly. They should be immutable.

I confused state and props. The distinction between the two has always been a bit hazy to me. I'm not sure what "non-reactive" means.

A React component is supposed to be a pure function, a mapping from props+context as input into an output which is a React element plus sideeffects (which when executed by the React library will often change the context). State lives in the context.

To illustrate statefulness: If you drop a flummy ball on the floor, it will bounce back and doesn't change. If you drop an egg, it will change and you can't drop it easily again. The ball is stateless, the egg is stateful.

> HOC's have a bunch of downsides, imo the most obvious one is the props; you need to pass the previous props, and merge in the new ones.

Render props (aka. "function as children") are much more free form than HOCs - they allow you to "compose the props" at the site of usage, as opposed to the component implementation.

I don't think there is a use case that HOC covers that cannot be done with render props - please correct me if I'm wrong.

You are not wrong, I think renderprops are valid, and I still use them in some situations.

They are imo not ideal as they are hard to memoize because of the render function. It’s funny that if you try to memoize renderprop components you likely have to use some sort of inputs array just like hooks.

Besides the memoization issue it also gets pretty messy if you need to implement many of them. Instead of just putting things in variables you are now nesting many levels deep.

I think renderprops and hooks are functionally not that different, but hooks have better ergonomics when using many.

I have a hook that I copy around between projects called `useViewport()`. All it does is watch the current viewport size and updates its value when that changes. Because it's a hook, I can call this function from any component body:

  const { width, height}  = useViewport();
  return <div>Viewport: {width} {height}</div>

Zooming in, this is just built from a useEffect() to bind event listeners, and and a useState() to hold the current value. Zooming out, it would be easy to write a useBreakpoint() hook that mostly just calls useViewport(). Hooks compose.

Before hooks, there weren't great patterns for isolating units of stateful logic from the presentational side of React. A really common pattern was to use "render props" where a component keeps some internal state and passes it into a function-as-child:

  <ViewportWatcher>
    {({ width, height}) => <div>Viewport: {width} {height}</div>}
  </ViewportWatcher>

You'd see these provider-components nested three or four layers deep, and it got ugly. Hooks solved this.

I'm not a react expert, obviously, but what would be wrong with this?

    class MyComponent {
        constructor() {
            watchViewPort((x, y) => {
                this.something += x + y;
            });
        }

        render() { /* ... */ }
    }

    watchViewPort(callback) {
        addEventListener("resize", (event) => {
            // get x and y
            callback(x, y);
        });
    }

This is obviously not production code, and I haven't tried it, so maybe something doesn't work? What is this missing that hooks provide?

Hooks let you colocate logic that, in class components, would need to be split across multiple lifecycle methods. In practice you need to remove the event listener when the component unmounts. You can get reasonably close to a hooksy API for doing this here:

    class MyComponent {
        componentWillMount() {
            this.stopWatchingViewport = watchViewPort((x, y) => {
                this.setState({ something: x + y });
            });
        }

        componentWillUnmount() {
            this.stopWatchingViewport();
        }
    }

    watchViewPort(callback) {
        const onResize = (event) => {
            // get x and y
            callback(x, y);
        };
        addEventListener("resize", onResize);
        return () => removeEventListener("resize", onResize);
    }

But being able to slice up logic by functionality, rather than by lifecycle event, gets gradually nicer as you have more of it.

> Hooks let you colocate logic that, in class components, would need to be split across multiple lifecycle methods.

I think the obvious OO alternative to hooks would have been this:

    class MyComponent {
        constructor() {
            this.attachBehaviour(new MyBehaviour(this));
            this.attachBehaviour(new MyOtherBehaviour(this));
        }

        render() { /* ... */ }
    }
    
    class MyBehaviour implements ComponentLifeCycleHooks {
        componentDidMount() { /* ... */ }
        componentWillUnmount() { /* ... */ }
        componentDidUpdate() { /* ... */ }
    }

Weird React didn't even seem to consider when they went to hooks. Would be possible to implement yourself though.

I'm not saying this is better than hooks / "composable" / "functional" API (I quite like Vue's composable API) but it's less of a departure from class based components.

Interesting you assume they didn't consider this. They probably did.

How do this two behaviours compose together/interact with each other?

I made no such assumption. I've just never seen it discussed, where as, for example, I've seen "mixins" discussed and dismissed (justifiably) as an alt.

> How do this two behaviours compose together/interact with each other?

What?

Departure from class based components was one of the motivations behind hooks, those are:

1. It’s hard to reuse stateful logic between components

2. Complex components become hard to understand

3. Classes confuse both people and machines

See https://legacy.reactjs.org/docs/hooks-intro.html#motivation for details. Agree or not, but it is a very intentional and well motivated direction.

Above was OO an based solution to #1, and arguably #2. Many would argue hooks did nothing to solve #2 and may have made things worse.

> Agree or not, but it is a very intentional and well motivated direction.

Agree with problem exists (roughly), disagree on solution.

Thats purely a React API limitation.

The hook API could be class based:

  class ViewportHook {
    // API on use
    constructor(component) {
      this.viewportState = component.addState(this, initialValue)
      const unsubscribe = watchViewport((x, y) => this.viewportState.set({something: x + y}))
      component.addOnUnmount(unsubscribe);

      // you can also use another hook - hook composition works
      this.otherHook = component.use(SubHook);
      // use the other hook's api
    }

    // API to expose (in render)
    value() {
      return this.viewportState.get()
      // use this.otherHook too if you like
    }
  }

You would be able to use it in a component like this

  class MyComponent
    constructor() { 
      this.viewport = this.use(ViewportHook);
    }

    render() {
      const viewportSize = this.viewport.value();
      // use in render
    }
  }

Boring, and a bit less weird.

How would passing a value from one hook to another look like, for example, Subhook requiring viewport value to set up some subscription?

Good question.

  component.use(SubHook, param)

could be used, that would pass the param as a second argument to the constructor.

The main reason why this isn't the case, I think, is concurrent mode. Hooks force certain values to be retreived and stay stable during render (i.e. you can only get a component state value during render function) and this is important if there are multiple setup and teardowns going on.

(Concurrent mode is IMO a bit of unfortunate React complexity that a lot of users of React don't really need, and many others can avoid)

This is a hook version of the same code as near as I could guess it.

  function useViewport(initialValue) {
    const [state, setState] = useState(initialValue);
    useEffect(() => {
      return watchViewport((x, y) => setState(x + y))
    }, [])
    return state.get();
  }
  
  // usage
  
  function MyComponent() {
    const viewportSize = useViewport()
    // use in render
  }

I made a couple of assumptions here. From usage, I assume watchViewport is supposed to both subscribe and return a teardown function. I also assume that the viewportState.set/get are functions for getting and setting the tracked value in the component's state.

In my opinion, there are many advantages to the hook version and several major disadvantages to the class version:

1. There's no need for hooks to have a value method or React.Components to grow the use or addState methods because the hook is just a function call which returns a value. How it produces that value is up to the code inside the function--which does call out to React--but the fact the function will always be called when MyComponent is called (absent something throwing earlier in the function body of course). The value you see being returned by the hook will always match the value you get when you call useViewport() in your component. These two things are guaranteed to have the exact same behavior as any other JavaScript function call and thus you can reason about the "registration" and value passing without needing to learn any framework-specific APIs.

2. There's no need for an addOnUnmount method on the component object passed to the ViewportHook constructor, because the hook function can use the function component's equivalent to componentWillUnmount (the return value of a useEffect) in the exact same way as a function component can, but without need for external registration.

3. In order to implement the class API, you'd need to either (A) pass the component's actual instance to the hook, or (B) create a new type of value to represent the instance of the component the hook is registering against. Option (B) is yet another API to learn, as you have to learn a new type of object to deal with in a React application. Option (A) would mean figuring out a way to prevent people from calling those methods after construction, OR introducing the possibility of registering a new slice of state partway through. The latter might be possible, and maybe that's even what you intend, but I'd want to know what the expected impact on methods like shouldComponentUpdate or getDerivedStateFromProps would be. Speaking of those...

4. I can't think of any obvious way you could pass previous versions of hook-related instance properties to lifecycle methods in the same way that you can pass prevProps and prevState.

5. Concision: the hook version has a dramatic reduction in the amount of code you have to read

6. Bundle size: because the hook version relies on functions rather than class properties, it can be minified trivially and thus reduce bundle size even more than the obvious reduction in character count would imply

The class version is

  class ViewportHook {
    constructor(component) {
      this.viewportState = component.addState(this, initialValue)
      component.addEffect(() => {
        return watchViewport((x, y) => this.viewportState.set({something: x + y})
      })
    }

    value() { return this.viewportState.get() }
  }

The hook version is

  function useViewport() {
    const [state, setState] = useState(initialValue);
    useEffect(() => {
      return watchViewport((x, y) => setState(x + y))
    }, [])
    return state;
  }

I changed the API to be more similar to the existing useEffect where you can return the unsubscribe function. That makes the difference in the size of code non-significant.

Again, its more about API design rather than classes or functions.

Another crucial benefit of the class version: you can use hooks in conditions or loops, in any order. This is because they're not called on every render. I also used a unique `key` to pass to `addState`, but its not really a requirement, since the hook constructors only get called once.

I don't understand points 3 and 4, can you elaborate? I'm assuming that when i call `component.use(HookClass)` the component creates a new instance of that hookclass. Regarding learning, I don't think the whole concept of (functional) hooks and their idiosyncracies are any easier to learn than learning one new type of class.

> Bundle size: because the hook version relies on functions rather than class properties, it can be minified trivially and thus reduce bundle size even more than the obvious reduction in character count would imply

I don't think this will make any meaningful difference. The full component methods API (addState, addEffect) is likely to be in use in any nontrivial project, so that can't be minified away. For 3rd party hook classes, they would be small and independend through `use` and easy to minify / dead-code-eliminate if not in use.

> I don't understand points 3 and 4, can you elaborate? I'm assuming that when i call `component.use(HookClass)` the component creates a new instance of that hookclass.

Sure! You show ViewportHook's constructor receiving a "component" prop. Since, in the calling component, you call this.use(ViewportHook), the `use` method is supposed to pass some sort of reference of the calling component into ViewportHook's constructor. My question was about what the type of that parameter is. Internally, is `use` something like `use(Hook) { return new Hook(this); }`? If so, you're passing a direct reference to the class instance. I had thought that maybe the framework could pass a more limited delegate for the instance to the constructor to prevent people from doing something silly with it, but that would prevent you from assigning a property safely anyway.

> I don't think this will make any meaningful difference. The full component methods API (addState, addEffect) is likely to be in use in any nontrivial project, so that can't be minified away. For 3rd party hook classes, they would be small and independend through `use` and easy to minify / dead-code-eliminate if not in use.

Object properties can't be safely minified. Any user-defined component using lifecycles will still need to have "constructor", "render", etc in the generated source, whereas identifiers (like "MyComponent" in `const MyComponent = ...`) aren't accessed by being looked up on an object, and thus can safely be minified to one or two character names. This was one of the motivations of the design of hooks. I believe it's called out in the original talk from React Conf 2018.

[Edit]

And regarding point 4: componentDidUpdate receives prevProps and prevState, and shouldComponentUpdate receives nextProps and nextState. How would you provide information about the previous or next version of that hook-based state if it's being tracked as an instance property rather than in the component's state object?

> I had thought that maybe the framework could pass a more limited delegate for the instance to the constructor to prevent people from doing something silly with it, but that would prevent you from assigning a property safely anyway.

That seems like a good idea. I'll admit my illustration is not a fully fleshed out design, it was meant more to be a sketch of how it would be possible to make a class based design much more capable than the original one was.

> Any user-defined component using lifecycles will still need to have "constructor", "render", etc in the generated source

Ahh I got it - this is not about DCE but about minified names. Not sure why my mind went with dead code elimination.

My first gut feeling is that this wouldn't be as important for everyday users if they already have code splitting / DCE / gzip. I'll look up the video, would be interesting to see some numbers - I'm hoping thats part of the presentation.

> componentDidUpdate receives prevProps and prevState, and shouldComponentUpdate receives nextProps and nextState. How would you provide information about the previous or next version of that hook-based state if it's being tracked as an instance property rather than in the component's state object?

I'm giving up having a single component state with the new API - this class based hook API also allows you to have multiple states. So I'm going to focus on the props part.

In the hook constructor, you would be able to use a listener for componentUpdate:

  component.onUpdate((prevProps, props) => { run code });

You could also do something like

  component.watch(() => [otherHook.someValue(), this.someState.get()], () => {
    // callback
  })

to get render-time change detection (equivalent to `useEffect(fn, [otherHookValue, someStateValue])`).

Its all a bit wordier, no doubt, but I feel that most of the capabilities can be implemented.

I imagine most of them could be, but this is an API which would require a lot of additions to the existing React.Component API, and would end up duplicating a bunch of already-existing functionality for something which in the end would probably need to conform to the same rules hooks do, but with what certainly feel to me like clunkier ergonomics. You'd also still be left with the problems of class components like poor minifiability and unreliability for hot module replacement.

I have to go to bed, but if you'd like to see a much better explanation about why hooks were adopted, I highly recommend the [checks notes] 1,401 comment-long discussion[1] on the PR for adopting the hooks RFC back in 2018, as this sort of design was brought up frequently. Especially worthwhile is Sebastian Markbåge's ending summary about why the team was going with hooks[2].

[1] https://github.com/reactjs/rfcs/pull/68 [2] https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148...

I was trying to discuss the merits or demerits of hooks overall - just wanted to point out that a class based design doesn't need to be significantly less powerful or HoC-level awkward to use.

(I can't resist commenting I suppose - I did follow that thread as much as time permitted back then, and I couldn't agree with the conclusion from the arguments presented. Specifically, I was unconvinced that dispatch performance and file size were that dramatically different. In my experience, classes are very efficient in modern engines and code-splitting means much more than minification, especially after gzip. Even if they are the right trade-offs for Facebook, its unclear whether they're the right trade-offs for the rest of React users and the community as a whole - from my experience it has errected a bit of a barrier to front end work for backend engineers because there is a steep and weird learning curve at the start)

I think the disconnect is reusability. You should not use inheritance class-based react components. Therefore, if you wanted this logic in another component, you either need to copy/paste it or use an HOC. Other commenters have shown why HOCs are a pain, so I won't give into it there.

Copy/paste gets even worse when you fix the bugs in your code: - use `setState` rather than update a prop - handle remove event listener on dismount

That extra code makes copy/paste even worse, so HOCs become tbe better option. Hooks are even better since they don't require passing callbacks into a component to get the data

You are also copy-pasting the hook line

> const { width, height} = useViewport();

This could be a library call from a component, using normal language constructs. In some languages it would be a service.

React is great, but I wished they stopped changing things every week.

Every week? Hooks are from 4 years ago..

Only new things now are suspense and server components, both completely optional.

React is amazingly stable and largely backward compatible (where it’s not there are usually codemods available to do most of the work).

Context is also relatively new, and capturing errors I believe was only possible with class components, or it changed recently.

Redux, mobx, etc also were all options to fix the basic state management in React.

I concede it is not every week. I should have said the preferred approach changes too often for my taste.

I believe context predate hooks. You are right about error boundaries, probably should be revisited.

This might be controversial but imo the lack of state management in React is a pro not a con. It means the community can innovate instead of being stuck with whatever the framework provides as is standard with most other frameworks. A lean focussed but flexible API.

You can choose the flavor that works for your, patterns like React Query, SWR, Zustand, the Atom based stuff, it's all a big #win imo. I like having options.

Also I'd say changes in preferences are not exclusive to React. React did make the hook change (while still supporting the old!), but otherwise the preferred approaches are not per se exclusive to React.

I would add that there is nothing wrong with sticking to what you are using atm. You don't have to use the shiny new thing if the old works well!

This is actually a perfect example for why classes are insufficient.

You've forgotten the teardown logic. If the user navigates from & to this component often. You'll add more and more listeners. over time.

The solution would be to store the teardown logic somewhere in a class field and then call it from a destructor.

Now this unit of logic is in three different places of the class. If you need to integrate multiple units, they interleave and the class becomes convoluted. Also it's easy to forget about the teardown.

Hooks can achieve this lifecycle awareness by default. They aren't the only solution though: Vues' refs and Sveltes' stores achieve similar results.

Take a look at Use hooks libraries for examples of code that you may want to have portability with (this is they typescript one because its the one I've used)

One of the simplest examples is "useToggle" which just sets a state variable to true or false. Not hard to write in a class component but it's still stuff that you may end up writing a lot.

A lot of similar ones are click and event handlers that need to be cleaned up after the component is unmounted.

useIsMounted is one I use a lot too to ensure I'm not trying to write state on an API callback once a component is unmounted.

You could add each of these to a class with an hoc and end up with withToggle(withIsMounted(withUseMediaEvent(MyComponent))) but that tends to be a bit of a mess.

https://usehooks-ts.com/

Hooks are much worse because they poorly emulate classes.

What you need for components is a stateful container, with an initialization phase, a render function that can be called for each update, and lifecycle methods that are called at lifecycle events.

Classes give you exactly this:

- Constructor for initialization

- Class fields for state

- A method for rendering that can be called multiple times, which can reference state

- Lifecycle methods

Classes are simple, standard, and give you everything you need for UI components. They were practically invented alongside the concept of UI components.

Hooks try to cram all of this into the repeatedly called render method and it's just a failure.

- You have to put initialization into callbacks because the whole component is called multiple times

- It's difficult to manage object and callback identity across renders requiring useCallback() and useState() to fix

- Lifecycle callbacks are put into hook arguments, but they're just trying to be methods and end up recreating the lifecycle closure every render.

- Hooks have restrictive rules on their usage

- Hooks make a function no longer just a function. It needs to be invoked inside a hook context, making it much less portable than a constructor

- Hooks hide their state within the hooks system, making them much harder to introspect and debug.

Hooks supposedly solve this composition problem and allow reusing logic, but that is entirely possible with classes. It's just a huge amount of FUD and misinformation to say that you can't do composition with objects. All you need is an object interface that is similar to the component interface that the component delegates to from its lifecycle methods. This is a simple and standard pattern to use and implement: it's just a single line of code per lifecycle method. And it's easily introspectable with a debugger: just follow object references to the helper objects.

lit.dev does with with reactive controllers: https://lit.dev/docs/composition/controllers/

It's a very simple alternative to custom hooks, and eliminates the need for all the builtin hooks.

100% this. Reading complex functional components is challenging because you're creating the functionality of a class with non of the organization.

How do you mean? Imo it's easier to organize as you can split up your logic into normal functions and custom hooks (which are also just functions).

I also find functions much easier to read as there is no "this" and you can simply read them top to bottom for order of execution.

So I spent some more time reading through using HOCs in React and I think I'll have to give functional components more of a try. The specific example I was thinking of is https://github.com/graphql/graphiql/blob/50674292c55eadf0e61... but this component will probably always be complex because of the Codemirror interaction.

Nice! I think you might like it.

Ah yeah, that does take a while to unpack. I think a lot of the complexity there is dealing with a non-react library and the dynamic import(s). Binding non-react libraries can be a bit rough.

I do think it's a good example to show the big advantage of hooks, if you look at the use of the hook, super clean: https://github.com/graphql/graphiql/blob/50674292c55eadf0e61...

Great way to contain complexity and make usage really clean and simple!

React functional components are not supposed to be complex. It's easier to split FCs up than in Vue for example. Even React's class based components discourage splitting components by adding more boilerplate.

Sounds like you should stop trying to think of hooks as classes. They're not.

I don't know where your downvotes come from.

It's a different paradigm, and twisting hooks to behave like classes clearly doesn't work. I partially blame it on React not properly updating their hooks docs in time (they're 2.5y late, ffs).

Hooks are the way to go, class components should have died a fiery death back in 2018, and at this point any other opinion is just wrong.

> Hooks are the way to go, class components should have died a fiery death back in 2018, and at this point any other opinion is just wrong.

To your snarky comment, I'll raise my own snarky rant from a while ago, about hooks leading to render loops that are impossible to debug: https://blog.kronis.dev/everything%20is%20broken/modern-reac...

It's probably not the kind of writing that I'd strive for nowadays but the error message not telling me exactly where the problem is felt unacceptable and clicking on the error source leading me to React code instead of the problematic lines in my code felt just unnecessarily weird.

I know that hooks are touted as the best way to extract reusable bits of code, however when multiple useEffect hooks have issues with dependency arrays and start causing render loops, clearly something is wrong.

Personally, I acknowledge that class based components are an easier mental model for many out there, but are also dead due to the direction that React is heading in.

But I would also suggest that the new Vue Composition API does hooks better than React and that using Vue with Pinia (instead of React with Redux) will overcomplicate things way less for developers who just want to get things done.

Skimmed over your article. The infinite loop situation is not exclusive to hooks and very much exists in classes.

The situation is calling setState from useEffect, which triggers a render, triggers the setState, render, etc...

If you setState in componentDidUpdate without any guards you will end up with the same loop. I don't remember how debugging this worked, but I'm pretty sure it wasn't pretty.

As to big messy components: I don't think you can blame that on hooks. Hooks make it easier to split all of that up so you have isolated well contained chunks of logic that are much easier to test, debug, and manage.

Vue; not super familiar but I believe they use reactivity right? I think reactivity can be nice, but is also not as great as it's made out to be as it gets tricky as soon as you need to take control and prevent extra renders etc. A lot of it is making diffing and memoization less explicit, which can be nice, but also has some tradeoffs.

THANK YOU. Very well said. I've been annoyed by hooks since they came out and you described my sentiments perfectly.

This kind of reminded me of the module pattern [1] popular with ye olde jQuery plugins. Just realized that hooks try to emulate what JS does natively, which is keeping track of all local variables in a functions calling scope. Meaning that if that function returns an object, that Object still has access to all the variables declared when that function run.

[1] https://stackoverflow.com/questions/17776940/javascript-modu...

Would generator functions help?

    function* Counter(props) {
      const [state, setState] = makeState(0);
      const incr = () => setState(state.value + 1)
      while (true) {
        yield <div onclick={incr}>{ state.value }</div>
      }
    }

Classes with state are a nightmare. You can never tell what has changed or where. Having the state in the hook system where it's visible to your tools and you can actually see what's changed between one render and the next is a huge win.

You can do that with classes too though. We use decorators to make class fields reactive and track what changed between renders.

Most importantly: hooks make functions that look pure actually impure.

Before hooks, if you wanted to call a functional React component, you could reasonably assume it's pure - it depends just on props and nothing else. Only when trying to use a class component did you needed to start to worry about it's internal state and how the lifecycle influences it.

With hooks, you are never sure until you look into the function's implementation!

Exactly! I could not put it better. All the talk about side-effects. Hooks make side effects more confusing, not less, for the reasons you perfectly explained.

Small rant ahead. Disclaimer: I find React very useful, just not this constant churn of approaches.

One solution would be to make all state pass through a single point (like Elm or Redux) but some people do not like this because it "limits" them. Limiting side-effects lowers cognitive load, same as Type systems are usually not Turing-complete. Limits can be good.

Same with Context, which is practical because you can write things from anywhere. Congratulations, we were concerned about side-effects and now we are basically using a global variable.

It is like some people talk about side-effects and functional programming and they think it involves using map and filter and done and they don't think deeper about what it means, and see no contradiction in it where it contradicts the principles they are promoting.

All true. I work on a massive React codebase and it is a challenge to follow the logic because at any given time there could be a dozen effects firing off from a single state change. Granted, having the dependency array helps follow what's firing off, but when effects kick off other effects it gets into a mess. (Probably a sign that we should refactor some things) This problem isn't solved by class-based components either; years ago when I first started working on the codebase I found class-based components with gigantic componentDidUpdate() full of hard to follow conditionals and setting state. That said, hooks makes it easier to refactor problems like this in my experience.

> Most importantly: hooks make functions that look pure actually impure.

What makes the functions look pure? Functions in JavaScript have no guarantees about purity. TypeScript won't let you make such guarantees either, and I think Flow won't either. The only way I could imagine something _looks_ pure is if you have prior expectations of what a function component should be from how they were discussed in very old versions of React before APIs like createRef existed. The preferred terminology from the core team these days is "function components" and has been for a long time. I've been using React since 2014 and they stopped talking about "stateless functional components" well before hooks were announced in 2018.

It’s funny that controllers are conceptually not that different from hooks just with classes. Question: can controllers access everything on the host? As that would easily turn into a giant mess. Probably you shouldn’t but isn’t that the same as hooks rules?

Classes have lots of rules and best practices to prevent a mess, just like hooks. Also stateful classes are notoriously hard to debug as everything can change everything all the time.

I think you also should try hooks for a bit. Some of your statements about them are incorrect or really not that prevalent in normal use, you might be surprised how nice they can be. Especially use react-query or swr for fetching and something like zustand for state.

Reply on news.ycombinator.com