React clicked really fast, documentation new and old, articles helped get on track really fast.

Wiring that all together and taming CRA (Create-react-app) with react-app-rewired to add stuff to webpack, like adding libraries to behave like modules that are NOT modules, packing all with scripts into single html, understanding where are boundaries between fluentui and react (both new to me), setting up monorepo because I separate reusable components from app itself and libs, applying css which I am bad at and stuff like that took more time... complexity just explodes, but less "mental effort" overall achieved by having streamlined build, reusable stuff etc.

Otherwise I feel that building app with react takes a lot of "mental effort" away, because you develop a component in isolation which feels simple and when you use that component you don't think about implementation details - it is nicely abstracted away and things just work.

Ah, yes, and I'm lucky I got the signal that functional components are way to go and the only place I had to use a small class component when I want to have a component variant for existing class based component from FluentUi where generic types are important and used within `onRenderItem` and various methods:

> class LookupBaseInternal extends BasePicker<ILookupResultProps, ILookupPropsInternal> {}

You probably want to look at vite for a more direct alternative to CRA. No need for things like -rewired, and it's probably 10x faster than CRA.

No such issues with Vite. It feels super light weight, snappy as hell and can run forever.

> There is currently no way to write an error boundary as a function component. However, you don’t have to write the error boundary class yourself. For example, you can use react-error-boundary instead.

https://react.dev/reference/react/Component#catching-renderi...

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!

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.

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);

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.

`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.

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.

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.

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

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.

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.

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

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

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

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

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

I hope that illustrates the key weirdness aspect of hooks.

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.

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!

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?

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

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>

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

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

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

    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);
    }

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
    }
  }

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

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

  component.use(SubHook, param)

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)

  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
  }

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

  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() }
  }

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

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.

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?

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 });

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

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

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 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 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() { /* ... */ }
    }

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.

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.

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

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

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

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

What?

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

> 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.

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).

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.

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!

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.

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.

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.

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.

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.

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

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.

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.

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/

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.

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!

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.

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.

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.

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!

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.

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.

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.

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

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.

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

Anyhow… To this day, I still think it’s an unforgiving, crazy beast of a library for a weekend hobbyist developer like me. But I kinda like it now and in big part it’s thanks to hooks, functional components and these new docs. Good job team, and congratulations on finally getting this live!

Regarding performance, I remember having blocking sluggishness with v-model that shouldn’t have been there back in Vue 2 days.

Also, for example, in Vue 3, my favorite component library Buefy (based on Bulma) is no longer available, and I don't think any of the other ones have (arguably) come so close and extensive to what I want.

Vue 2's transition to Vue 3 (if you want to use the new CLI tools and the Composition API) had to, by definition, fragment the ecosystem in unpleasant ways no matter how carefully and sensibly it was managed by the core teams in charge.

You can see that Vue went down slightly in recent developer surveys, and I suspect this to be among the main reasons. As if Evan himself would be suddenly more focused on his build tool Vite as opposed to Vue itself (of course it's just an illusion).

But I still love Vue because of their amazing docs, and the fact that they let me enter the world of web-development in a relatively accessible manner (this may not have been possible with React, for me personally). Lack of something like scoped styles alone baffles me in React to this day, but it makes kinda sense in the ecosystem it's operating in...

Worth noting: we've been enabling SSR for React since 2016[1], and some of the largest websites on the internet SSR with Next.js: Twitch, Hulu, Nike, and even parts of Amazon[2]

[1] https://vercel.com/blog/next

[2] https://twitter.com/rauchg/status/1594779272945627136

I had a look at the component libraries that are compatible with Vue 3 a while back and concluded that either PrimeVue or Quasar are some of the better choices for my web dev needs.

Surprisingly, many of the formerly popular options are stuck with just Vue 2 support.

Once you do that, React becomes purely functional (and quite "uni-directional", if that's the right term). Just update the state (in an event handler or when a Promise resolves after a fetch or another part of the UI finishes) and UI auto-magically reflects that on the screen.

Arguably, MobX + React is closer to the React's original ideal of `UI = f(state)` than the vanilla React itself.

I thought Zustand is kinda simplified clone but seems like computed properties don’t work super well.

The difference between this and rreact is less typing, easier mental model and less issues (because react calls render() multiple times)

I'd say in Vue it rarely causes troubles, in React world it leads to few non-obvious edge cases where React's one way data flow is indeed easier to reason about (but less performant).

It has much better Typescript support, and also it doesn't have Vue's spaghetti reactivity system, both of which vastly increase the chances of bugs.

I guess you could say they're more similar if you simply don't care about bugs at all.

Vue 3 has excellent TS support.

Finally, if you combine it with the fact that it seems to hold on as the industry standard for jobs, and being useful for native mobile development via React Native, it all comes together nicely in my mind. With its huge ecosystem and closeness to plain vanilla JS, I guess it just makes me simply a bit of a better developer and gives me a new perspective on things. That's that.

Then again, the whole front-end ecosystem is moving at a pace I cannot quite follow. Instead, I've been going into the direction of traditional monoliths and working through the docs of Django and RoR.

There you have a plain "good-old" templating language with sprinkles of htmx and alpine where you need it. This along a bunch of back-end devs that seem to not want to even touch the javascript stuff with a stick. It almost feels refreshing though, particularly if you want to build rapid MVPs while retaining maximum control of your entire stack and IP. When teams grow and you need to support extensive and/or thicker clients, I believe this is where bigger front-end libraries like you mention truly shine. I'm still counting on us coming a full circle and there being a re-emergence of traditional monoliths in the future though. But then again, with supabases, pocketbases, strapis and other "simpler" backends of this world, who knows what'll be happening even in the nearest future...

Side note: I recently took an assessment test on React through Triplebyte and was given an expert level badge (for what it's worth). I think that speaks volumes about the new React docs because that is where I gained most of my React related knowledge.

Having a dedicated place to process changes in props and setup/teardown logic is just generally nicer than weird dependency arrays and returning destructors from effects.

See here for some examples of how you can approach writing the same code in a few different ways -- maybe one of these styles will fit you better: https://react.dev/learn/reusing-logic-with-custom-hooks#ther...

There are downsides to this - you do need to think a lot more about code architecture before implementing the code, and you can get into a really messy/unmaintainable situation if you aren't careful. And you'll need to consider what state your "singleton" is tied to - is it really one per page, one per component, etc? And depending on the answer, the implications may be that this pattern isn't a great idea. But for certain use cases, it can work well.

The core premise of this pattern is separating business and UI logic, which is not exactly a new idea.

[0] https://www.searchkit.co/

[1] https://github.com/algolia/instantsearch

[2] https://github.com/searchkit/searchkit/blob/main/packages/se...

React apps should, in general, contain much less react-specific code than they tend to.

Should make it easier to switch frameworks in the future if the need arises.

Regarding the link, I most likely wouldn't consider routing and bundling to be in that list. Sever integration currently doesn't apply to me, since our app is one of the cases where CSR makes more sense.

is there a good reason not to uniformly rely on useReducer everywhere in a codebase?

In the popular sense, they've been on the down and out for years now.

> It turned in to a bit of a mess until I went for a refactor into classes and everything became much more clear.

in my experience, once the logic starts to become complex, you need to develop custom hooks so that a given component stays readable.

The hooks paradigm is a lot harder once you get past the basics, but I wouldn't go back for reasons I could articulate if there's any interest.

I hate hooks. The syntax feels nice to type, but the issues outweigh the benefits for me. It’s way too difficult to understand the rendering lifecycle, the state updating, the ordering and I also find the reuse abstraction hard to follow (although I accept that might be a concentration/attention issue on my part). Conversely, it’s also way too easy to break the purity of the hook callbacks, so hooks can use state from contexts you wouldn’t expect (more an issue with custom hooks if you don’t also supply linter tooling to go with them).

Why do you prefer them?

Obviously using hooks doesn't mean it has to be shitty, I think it just brought a lot more wannabe React devs that have no experience with architecture or maintainability.

I tried to give it a real shot with hooks, but the marginal benefit they bring seems to be far outweighed by the added complexity. Add to that the mixing of paradigms with some functional components, some class-based, etc and it becomes a mess pretty quickly.

Class components are just (IMO) cleaner, and I find myself saddened at the level of disarray most codebases with hooks are nowadays. Enough has been written elsewhere about how hooks require one to keep more in their head; class components have an agreed up layout/structure/etc that is important in large codebases.

It's just frustrating. Couldn't they have had the decency to fork / rename React for all this and leave the old branch to die instead of turning the entire space into some kind of pedantic war-zone for several years?

IIRC They reported that hooks were a common source of problems.

Visually they look simple but they hide a lot complex and nuanced semantics. Once you start layering and composing it becomes hard to reason about when a value updates, when a re-renders will occur, and when a value even resolves(it may take many re-renders for a value you need to finally get set).

Class components are still the only supported way to create an error boundary. Other than that, they are pretty much dead, yes.

The hook system is the parts of an OO system that React needed to be able to keep developing features & optimizations for function-based components, rather than telling their users & devs that they'd simply have to use classes for some things. It exists so they could side-line class components, rather than having to become outright reliant on them for some features. So, pretty much, yes.

We recommend defining components as functions instead of classes.

Not dead but they are not recommended anymore.

To this day if I need to do something in React I can pick it up quickly because is a very simple model: it follows the template design pattern, which is one of the most powerful and dumb design patterns (I'm talking obviously about the class model).

What's my current issue with React? Well in the same way that they have decided to go with hooks and all that, nothing is preventing those folks tomorrow to wake up to say: "You know what? What we really really need is not functional components but a hybrid approach, not fully functional not fully object oriented" and then the game starts again.

I worked for a very limited time in one company not long ago, and a guy there came and said something like: "We really should start using hooks" and I replied: "Really? Why? Can you show me a true or concrete advantage using the functional style over the OO approach?" then he said: "Well, I don't really need to do that just watch this video" and sent me a link of a video (if I recall correctly) of the creators explaining all the hooks stuff. I didn't even bothered to continue discussing (how can you discuss when someone is 100% biased?).

My point is that many people out there just take for granted whatever ideas these people are pushing out and not questioning things anymore. I'm not saying that hooks are good or bad a thing (I really don't know and if I need to learn hooks because that's the style used in a codebase, sure I'll do it and probably learn something), but blindly embracing things just for nothing is harmful.

So we sat down and actually used hooks for a few days - refactored small and large components to be sure we understood them and saw the difference in the code. We found it to be a perspective change -- once we made that change and got used to the new syntax, we loved it. Our code was simpler and easier to maintain. Once we really learned when to use useEffect so as to not abuse it for everything under the sun... the code got better still.

So while you are correct that blindly embracing hooks would be harmful... Blindly rejecting them is equally harmful.

Having said that, there are some gotchas with hooks that aren't trivial and can make them difficult to use/understand without significant comments. But hey, what code doesn't fit that description?

I understand the "it's dominant and has a large ecosystem" argument, but I just can't wrap my head around how enough people chose it for it to reach this position.

I've evaluated it a couple times and it just looks poorly conceived. Fixes and "improvements" have rolled in, but they are also poorly conceived and themselves need fixes.

Of course I know it might just be me... I didn't get the point of tailwind either, until I used it.

But I've also used react for a reasonable sized project and I still don't get it.

> what do you prefer

Svelte, for the case you mention.

I'm curious what you mean by "declaratively", and I wonder why everyone puts so much value into that particular idea. What is declarative? Is it different/better than using pure functions? Why? If not, why doesn't HTML have (pure) functions?

Pure functions are declarative. It's flexible so you can push it to the point where it's essentially a tortured imperative form, but you're probably doing wrong if you get to that point.

The goal of react and other web UI libraries targeting browsers and web views is to render HTML, but dynamically, based on the immediate application state. HTML isn't dynamic and we naturally want to use Javascript for the dynamic part (due to history and Javascript's great flexibility).

You can use HTML for the HTML and Javascript for the dynamic stuff. A lot of things work this way. But react decided to use Javascript for both the HTML and the dynamic stuff. JSX mitigates this to a degree, but it actually represents XML, not HTML. Thus you use className instead of class, close <input> tags, etc.

Edit: there are a lot of good--and varied--explanations here. Which is why I think the docs should cover it in-depth. It's confusing.

In reality we use a linked list rather than an array. If you wanna dive into the code, I can give some pointers. For example, useState is implemented like this during first render (https://github.com/facebook/react/blob/87c803d1dad7e5fe88634...) and like this during next renders (https://github.com/facebook/react/blob/87c803d1dad7e5fe88634...).

However, _conceptually_ I'd recommend to think of Hook return values similar to "extra inputs" to your function, kind of like extra arguments. There are different ways to formalize it in different languages. We picked plain function calls for simplicity and low overhead, although you could imagine `yield` with generators or something like that.

Why a LinkedList rather than an array?

Within the component functions's body, you may have many calls to the same hook, lets take useState() as an example.

Each useState() returns a different state variable, that is kept track of in a cache outside the component function.

On the first render, the state variables are created. On subsequent re-renders, the state variables are read from the cache.

The cache is a simple array. It keeps track of, and identifies each individual state variable from it's index in the cache array.

The first call to useState() gets slot 0 in the array, the second call gets slot 1 and so on and so forth..

For the tracking to work consistently, all calls to useState() within the function's body must also happen consistently.

In the same order, every time. Having a useState call within a conditional "if" branch breaks that consistency.

- React has a module-scoped variable in the hooks implementation file that tracks which component is currently rendering

- The internal "Fiber" data structure that describes a component instance has a linked list of hook contents (saved values and callbacks)

- As each hook gets called, React tracks the current hook entry, looks up the current hook data, and returns it

So, the number of hooks used needs to be the same each time the component renders so that the linked list entries match up consistently.

There's a great talk by @swyx here that builds a miniature hooks implementation in about 30 minutes:

https://www.swyx.io/hooks

If you were to call them in an "if" branch it would mess up that queue mechanism.

1) A hook adds a function or variable to one of several lists attached to the component object, when it's instantiated (yes, even your "functional" components are objects, and I don't just mean in the JS-functions-are-actually-objects sense—at least, they were when I read it)

2) Subsequent calls either call those functions, or accesses/modifies the value, in a FIFO manner, reading them out of those lists. This is why you can't mess with hook ordering in e.g. loops.

It's basically just methods and properties on an object, but with FIFO access based on declaration order, instead of using a lookup table of some sort.

[EDIT] A poster correctly pointed out (then deleted their post) that I wrote "loops" where I meant "conditionals". Technically sorta-true (though not quite, as phrased) if the loop isn't the same length every time, but yeah, I meant conditionals. Point is, the reason order matters is that the whole thing's just a bunch of FIFO queues, more or less.

So there is a data structure that store says `[useMemo, useState, useEffeect]` - and when you component re-renders, is unmounting, or has effects to trigger it uses the index order to lookup the bit of state that needed to persist.

This is a pretty good high level explainer of how react works that touches on some of that: https://overreacted.io/react-as-a-ui-runtime/

2. React counts the number of executions of (certain) hooks. This count is how it knows which state to get from the store as a return value from `useState`. useState is effectively `getStateAndSetter()` but it doesn't pass a key name of any kind, so the implicitly passed key is `hookCount++`. This is why you can't call hooks conditionally, or state would get all messed up - if a condition turns false and one hook doesn't run that render, all getStateAndSetter calls that run after it will be off by one.

Also, I'm curious if there is any similarity between these React hooks and the infamous Drupal hooks.

Not familiar with Drupal.

React hooks is running on each component, not on whole app. React app is composed by bunch of components, and each of those have their own hooks.

Additionally, this context would also have the context of children elements, so things can actually be persisted across function calls and React can know what needs to be mounted & unmounted.

Also note that because Tagname isn't called directly, it's also how React is able to do its diff and only actually call what is needed.

This is also why if you're generating a dynamic number of elements (ie outputting an array of elements), you should provide a `key` prop, so it can link up the elements to their corresponding past states each time the function runs.

https://react.dev/learn/updating-objects-in-state

https://megous.com/dl/tmp/zyrzbzjqxccvvdniorpj.webm

(Top of the line desktop AMD chip.)

The code has no transition, no setTimeout, no nothing that would indicate any delay. The dot should always be right under the cursor. This will happen with every similar UI pattern (want to resize something, move a slider, etc. etc.)

I guess this is a result of tradeoffs React has to do by insulating people from DOM.

There's probably some way to force immediate DOM update, but then you're pulling in a lot of useless diffing and checking for each frame, instead of just updating the single el.style.something property you'd do when directly using DOM API and leaving the browser to do the rest.

Draw a software cursor, and the same exact thing happens.

In fact, in effect, the red dot is a software cursor.

You can accomplish visualizing the same lag in a traditional update-draw loop in game software.

Cursors are special. Sibling comments here don't experience the same effect, because they're running displays at higher refresh rates.

That's it.

I guess you can take your cursor position at the beginning of scanout of the previous frame, render the new browser layer content, tell the compositor to update both cursor layer position, and browser layer at the next scanout, and both should have matching positions on the next frame. Maybe if the compositor is updating the cursor layer position from mouse position known right at the momen of atomic commit, there may be some difference.

Well, this is Xorg I'm using, and it's not using atomic DRM API, so things are not well synchronized.

Look at your profiler. Notice any significant overhead? You don't.

Implement this same thing using events and `.style` directly. You will get the exact same result.

The pointerEvent => style feedback loop is unfortunately very slow, more or less so in different browsers/operating systems.

Interesting that you would know so little about this and yet feel confident enough to make a proclamation like this is evidence of React's performance.

A similar issue occurs with native scrolling and fixed position elements whose positions need update every frame. You must take control of the scrolling in JS in order to prevent jitter.

Slightly off topic but my M1 Pro Apple Silicon Mac does not lag like your top of the line AMD chip.

I know most consumers run React code with CPUs slower than Apple Silicon chips but this post is more of an endorsement for the M1 lineup.

So you just need an M1. The M1 Air is frequently on sale for $800 nowadays. Or if you're really on a budget, you can buy a used M1 Mini on eBay for $400. Very affordable for those who want high browser performance.

So this should be `ref.current.style = {x: <whatever>, y: whatever}`. It's also a great use for useImperativeHandle() if it gets any more complicated. This is the example from the docs updated to use a ref: https://codesandbox.io/s/lucid-grothendieck-iquzfj?file=/App...

On this example it pretty much looks the same, which I assume is because of what the sibling comment says, that any cursor drawn in software is going to be slower than in hardware, and the animation and app are trivial so the rerender is basically free. But this way is still better, and it'll be more obviously better if the components being animated are complex. There's not going to be any way to do it faster in JS, but React can be a lot slower depending on what happens on rerenders (which is often, if using imported components, somewhat out of your control).

And they just handwave it away in the docs with an imaginary future API. Embarrassing.

Honestly, by the time class components are fully deprecated, you'll probably be able to ask ChatGPT to rewrite your codebase to use hooks instead...

Add a router like react-router and you have another 20 apis.

Add on top of that a state manager, even small ones, and you're adding another 10/15 apis.

The world has embraced hooks, for better or worse. The fact is React still works well, and the React team has always been clear that performance is (somewhat) an implementation details. For example, they often advertise to use inlined functions and to use `useCallback` only if you're facing performance issues.

So `useCallback` invalidation is definitely not "fundamental" (imho)

I hope the irony of criticising a team for launching something early, on HN _of all places_ isn’t lost on you.

> going all in on hooks

They went all in on hooks in 2018 when they rewrote the internals with React Fiber.

Hooks are how react works, class components are more of an abstraction—not less.

> while the fundamental problem with them, which was raised in 2018 is still unsolved

If it was a showstopper it would have been fixed by now.

    export function useMemoOne<T>(valueProducer: () => T, deps: unknown[]) {
      const [initialValue] = useState(valueProducer);
      const memoizedValue = useRef(initialValue);
      const memoizedDeps = useRef(deps);
      if (
        deps.length != memoizedDeps.current!.length ||
        _.zip(deps, memoizedDeps.current!).some(
          ([dep, memoizedDep]) => dep != memoizedDep
        )
      ) {
        memoizedValue.current = valueProducer();
        memoizedDeps.current = deps;
      }
      return memoizedValue.current;
    }

    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    export function useCallbackOne<T extends (...args: any[]) => unknown>(
      fn: T,
      deps: unknown[]
    ) {
      return useMemoOne(() => fn, deps);
    }

Specifically, I used sycamore-rs to build a Rust/WASM UI, and it's great (once you get the hang of dealing with lifetimes in sycamore).

https://github.com/reactjs/rfcs/blob/useevent/text/0000-usee...

- To avoid re-triggering stuff from Effects, we _are_ adding a Hook. It has the same API as the original `useEvent` proposal but is more tightly scoped to this particular use case (and different semantics). We'll submit a new RFC for it after some more testing, but it's available (as `useEffectEvent`) in experimental builds, and the docs mention it: https://react.dev/learn/separating-events-from-effects#decla...

- To improve rendering performance, we are working on an automatic compiler that analyzes your code and makes rendering much more granular. It's still in active R&D but we hope to share an update on it soon.

We think these two things together will likely be able to mostly address the issue. If not, we'll look at the specific gaps and work on them more closely.

In general though, people have shipped huge apps with Hooks, and it's definitely production-ready. Always an opportunity for improvement, sure.

There’s always a lot of complaining about hooks but honestly I think they’re generally pretty wonderful. Occasionally you need to do some gymnastics but more recently I’ve lent on the useEvent pattern to detach reactive and non-reactive code and it’s working nicely.

Is there something I should know about useEffectEvent vs useEvent? We use the pretend / poly fill version and I understand it behaves slightly differently. But in general we just want a function that doesn’t change that always calls the latest version of the real function. Mostly we’re passing it down to other components that use it as an event handler or sometimes in a useEffect themselves.

As ever, thanks for the work on React.

Yea. It still proxies to the latest version, but it doesn't give you a stable function. (In fact, it always gives you a new one in DEV to avoid depending on its identity.) Instead, the _linter_ lets you (actually, forces you) to omit it from dependencies. Conceptually, it's a non-reactive piece of code. There's also a new limitation that you're supposed to only call it but not pass around (also enforced by the linter). There's a bunch of reasons for this design which we'll write up in the RFC. (TLDR: you only really know whether something should be reactive or not next to the actual callsite.)

Though, in our case we use mobx so a lot of our components are effectively memoised on shallow prop comparison. Here the ergonomics of stable function identity work well at a higher level in the stack. You can avoid rerendering large parts of the tree if your event handlers are stable.

I’m a little worried that the api you describe will work against us here (and I’m also generally a little concerned that the smarter compiler stuff you guys are working on might not play as nice with a mobx world - but maybe that’s not true).

> * Only call them from inside Effects.

> * Never pass them to other components or Hooks.

(https://react.dev/learn/separating-events-from-effects#limit...)

The original proposal was more about `events` this one is about effects.

According to these rules, i can't do

    const x = useEffectEvent((event) => console.log("abc"))
    return <MyCustmButton onClick={x}/>

If these are passed down you’re invisibly breaking the reactivity of the child components. It’ll be too easy to shoot yourself in the foot in a child component by assuming that that you can use one of these in your own useEffect.

Like, do you know if there is actual example somewhere, where things break? They (react devs) only talk about something concurrent, but no actual code, only hand waving potential dangers.

Alas, since it's being "promoted" in the React doc examples I'm guessing I haven't seen the last of this :|

On-topic: I read all that and have no clue what useEffectEvent does. Why can't I just use a closure? Passing the effect event is listed as a limitation, but it's never explained why it can't be passed. What happens?

And what do we get from the React team? After five years? More vague promises. More RFCs. More blog posts. More tweets. More docs mentioning nonexistent APIs. No actual shipped solutions. Forgive me, but I just don’t believe you anymore at this point. Five years.

I think it's fair criticism we've been slow on shipping this Hook. We try to take a very cautious approach to introducing new APIs, so we are currently testing it in our internal codebase. Once we feel confident the approach makes sense, we will make a stable release with it.

You’re obviously a bit frustrated but as someone who has done a lot of React over the years I don’t quite get what you’re running into that would make you that upset.

Hooks has made me 3-4x more productive. If a technicality is stopping you from enjoying it, that is such a shame.

Here's my implementation, for the record: https://pastebin.com/rjj0FDDd

Even after years of writing fullstack javascript this is my first time seeing AbortSignals, probably because nobody uses them. Some libraries, like Axios, handroll their own cancellation mechanisms, but that does not really cut it.

This implementation doesn't account for the fact that the promise may settle after the component has been unmounted.

Hilarious! As someone who was once a "full-stack" web dev in the age of jQuery, CSS resets and local fonts only, this definitely rings true.

And having just started learning React (through Next.js), this is a timely and welcome refresh! Thank you!

This worries me a bit because some React wrappers for ClojureScript expose macros that essentially compile to React.createElement() calls, which are now labelled as a legacy API.

It also looks like Class Components are officially deprecated, given that the documentation explicitly states they are not recommended for use in new code.

We're not removing createElement but I'd recommend to change your wrappers to the same compile output that the new JSX transform (introduced in 2020) uses: https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n.... The new JSX compile target will allow us to do a bunch of optimizations in the future that createElement() can't.

I'll make a note of adding this to the docs.

In our embedded/plugin component scenario where we are given a <div> to load in, it appears we should replace our current pattern ReactDOM.render(React.createElement(... with createRoot(_jsx(....

Yeah you want

const root = createRoot(domNode) root.render(<Stuff />)

(or the JSX transform output equivalent)

Supporting some features for hooks and classes, both, probably would have meant having two implementations in some cases, that might not quite match up as equivalent. More API surface area, more code to test, more combinations and paths to worry about.

> And aren't classes just really functions under the hood anyways?

Other way around, actually: "functional" components end up represented by an object.

No, they're functions.

Component _types_ are defined as either classes (`class MyComponent extends React.Component`), or functions (`function MyComponent(props) {}`).

Internally, React has a "Fiber" data structure that stores references to that component type for each component instance, as well as a lot of other metadata. That's the _real_ "component tree":

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

In other paradigms, it is! Our paradigm is exploring the functional take. I agree it's a bit unorthodox but we are very intentional about modeling it that way. It really has a bunch of powerful properties one might not expect.

>And aren't classes just really functions under the hood anyways?

The key difference is that in React, UI is a pure projection of current data (props/state). You're always supposed to "return" the UI. Sure a class is a function, but that function is invoked once. Its methods can be called many times, but having a pure render() method (like in class-based React) is really a class cosplaying as a function. Functions are more honest to what React is trying to be.

Relevant part from Seb's Hooks RFC comment (https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148...):

> Classes may seem like the ideal thing to hold state since that's what they're designed for. However, React is more written like a declarative function that keeps getting executed over and over to simulate it being reactive. Those two things have an impedence mismatch and that keeps leaking when we think of these as classes.

>Another issue is that classes in JS merge both methods and values on the same namespace. This makes it very hard to make optimizations because sometimes methods behave like static methods and sometimes behave like values that contain functions. The Hooks pattern encourages the use of more statically resolvable calls for helper functions.

>In classes, each method has its own scope. It causes issues like us having to reinvent default props so that we can create a single shared resolved object across those. You also encourage sharing data between those methods using mutable fields on the class since the only shared thing is this. This is also problematic for concurrency.

>Another issue is just that the conceptual mental model for React is just functions calling other functions recursively. There is a lot of value to express it in those terms to help build the correct mental model.

For a concrete example of where classes as a model fails us, consider useTransition (https://react.dev/reference/react/useTransition). It lets you start rendering "in background" with a different state value. But if you get interrupted, the renders have the current value. This highlights that in React, the same piece of state can conceptually be thought of having more than a single value (kind of like being in parallel worlds). Classes don't model that well.

The operative word there is 'exploring'. In practice, hooks are still basically OOP, albeit masquerading as FP. You just shuffled the state into a shadowy realm adjacent to the component where it's harder for developers to see. I know a lot of JS developers are allergic to writing the 'class' keyword (even though JS doesn't really have classes in the first place), and I guess hooks help them sleep easier at night by allowing them to believe that they're writing their code in a functional way. But they usually aren't. And I think that misdirection is the source of a lot of the confusion out there regarding hooks.

"The greatest trick the OOP devil ever pulled was convincing the world that state didn't exist"