15 ms·

Why did react (effectively) get rid of class components? Conceptually, a component seems better represented by an object/class than a procedure/function. And ar

by kayson 4y ago

Why did react (effectively) get rid of class components? Conceptually, a component seems better represented by an object/class than a procedure/function. And aren't classes just really functions under the hood anyways?

pyrolistical 4y ago
The quick answer is Hooks killed class
- epolanski 4y ago
  We removed boilerplate for higher complexity. We made the 90% cases simpler but overly complicated critical paths. So many useMemo, useEffect, useCallback madness was trivial with basic class component lifecycle.
yamtaddle 4y ago
> Why did react (effectively) get rid of class components? 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.
- robertoandred 4y ago
  > Other way around, actually: "functional" components end up represented by an object. No, they're functions.
  - yamtaddle 4y ago
    Weren't as of a couple years ago—they're represented by an object in the React code. Not the case anymore? I'd be surprised if they'd messed with that, it seemed pretty fundamental to how it operated—hooks were implemented on top of that, for one thing.
    - robertoandred 4y ago
      Nope, just functions. Hooks are also just functions; their "magic" comes from them being called in the same order in a component.
      - yamtaddle 4y ago
        OK, so the core of React changed and they no longer use a "functional" component to build a component object, which used the be the primary data structure in the state-machine-like engine at the heart of react, and to which they used to attach the lists that contain a component's hooks? That's all changed?
        acemarke 4y ago
        The two of you are talking past each other :) 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-mostly-complete-guide-to-react-rendering-behavior/#component-metadata-and-fibers https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
danabramov 4y ago
>Conceptually, a component seems better represented by an object/class than a procedure/function. 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-439314884 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 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.
- notpachet 4y ago
dbbk 4y ago
I'm really not sure why they're so insistent on phasing them out. Have I written one recently? No. But I sure do appreciate that they exist for cases where you want fine grained control over what's happening.
wetpaws 4y ago
The original reasoning was, I kid you not "cause classes are too difficult concept to understand".

by kayson 4y ago

pyrolistical 4y ago

The quick answer is Hooks killed class

epolanski 4y ago
We removed boilerplate for higher complexity. We made the 90% cases simpler but overly complicated critical paths. So many useMemo, useEffect, useCallback madness was trivial with basic class component lifecycle.

yamtaddle 4y ago

> Why did react (effectively) get rid of class components? 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.

robertoandred 4y ago
> Other way around, actually: "functional" components end up represented by an object. No, they're functions.
- yamtaddle 4y ago
  Weren't as of a couple years ago—they're represented by an object in the React code. Not the case anymore? I'd be surprised if they'd messed with that, it seemed pretty fundamental to how it operated—hooks were implemented on top of that, for one thing.
  - robertoandred 4y ago
    Nope, just functions. Hooks are also just functions; their "magic" comes from them being called in the same order in a component.
    - yamtaddle 4y ago
      OK, so the core of React changed and they no longer use a "functional" component to build a component object, which used the be the primary data structure in the state-machine-like engine at the heart of react, and to which they used to attach the lists that contain a component's hooks? That's all changed?
      - acemarke 4y ago
        The two of you are talking past each other :) 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-mostly-complete-guide-to-react-rendering-behavior/#component-metadata-and-fibers https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

danabramov 4y ago

>Conceptually, a component seems better represented by an object/class than a procedure/function. 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-439314884 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 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.

notpachet 4y ago

dbbk 4y ago

I'm really not sure why they're so insistent on phasing them out. Have I written one recently? No. But I sure do appreciate that they exist for cases where you want fine grained control over what's happening.

wetpaws 4y ago

The original reasoning was, I kid you not "cause classes are too difficult concept to understand".