4 ms·

> They have their place. How so? There is nothing that a class-based component can do that a hook-based component can't (EDIT: Except for error boundaries). I'

> They have their place. How so? There is nothing that a class-based component can do that a hook-based component can't (EDIT: Except for error boundaries). I'd go as far as to say class-based components are strictly inferior because they force you split your behavior logic across lifecycle methods and are not easily composable. I've been able to support much more complex behavior easily with hooks (e.g., connection management), that would have been a nightmare with class-based components.

tshaddox 4y ago
You still need to use class components for error boundaries. https://reactjs.org/docs/error-boundaries.html https://reactjs.org/docs/error-boundaries.html
- ajkjk 4y ago
  Yeah, this feels like a weird oversight.
  - tshaddox 4y ago
    A bit weird, although it’s not clear how they would do it without class components. I guess it would probably look something like React.forwardRef.
    - ajkjk 4y ago
      They could provide a <ErrorBoundary> component as a built-in that just does what the current one does, but is implemented by the library.
k__ 4y ago
Isn't it also easier to get subtle lifecycle bugs with them, because you can forget one.
- phailhaus 4y ago
  Oh yeah, that's the worst. Since logic related to a behavior must be split up across multiple methods, it's really hard to tell if you've actually implemented it correctly. With effects, the setup and teardown is in the same function and can be moved around as a unit.
- deckard1 4y ago
  I don't know that I agree with that. I recently had to fix a few bugs because some devs forgot, or simply didn't know, that lifecycles still exist. We have reached a period of time where junior devs exist that did not cut their teeth on class components and have no idea of what the lifecycles are. They don't know how rendering works so they either throw up useless memoization everywhere or they don't bother to think of it. The complexity of class components did not vanish. It was only swept under the rug. Take useEffect. It's overloaded to hell and back. It does too much and people continue to struggle with it. Another one, useRef. It's not really for refs, per se. You will end up using it for data other than refs because function instance variables aren't a thing. No one knows when to use useLayoutEffect or useCallback. The fact of the matter is that it's not class components vs. hooks. It's that React's API sucks. It's always sucked. And it continues to suck.
  - phailhaus 4y ago
    > I recently had to fix a few bugs because some devs forgot, or simply didn't know, that lifecycles still exist. And then it just stays fixed. You don't have to split up the logic across different lifecycle methods and remember to keep them in sync. They're consolidated into functions that can be trivially pulled out into their own hooks and reused. React is definitely a more low-level framework that requires you to have some familiarity with how the scheduler works, and could benefit from a couple more built-in hooks. But the benefits are undeniable, they make writing and refactoring complex applications an absolute breeze. The fact that you can factor out some state-related behavior into a hook and trivially reuse it is incredible. For example, take state. With hooks, you use useState. A very common pattern is to need to persist it in the URL to enable deep linking. You can literally just replace your useState call with useQueryParam from the use-query-params library [1] and have your component function identically. You just can't do that with class-based components. [1] https://www.npmjs.com/package/use-query-params https://www.npmjs.com/package/use-query-params
theteapot 4y ago
> I'd go as far as to say class-based components are strictly inferior because they force you split your behavior logic across lifecycle methods and are not easily composable. That's not strictly true. You can implement "hooks" on top of a class based components. It's essentially the strategy pattern.

tshaddox 4y ago

You still need to use class components for error boundaries. https://reactjs.org/docs/error-boundaries.html https://reactjs.org/docs/error-boundaries.html

ajkjk 4y ago
Yeah, this feels like a weird oversight.
- tshaddox 4y ago
  A bit weird, although it’s not clear how they would do it without class components. I guess it would probably look something like React.forwardRef.
  - ajkjk 4y ago
    They could provide a <ErrorBoundary> component as a built-in that just does what the current one does, but is implemented by the library.

k__ 4y ago

Isn't it also easier to get subtle lifecycle bugs with them, because you can forget one.

phailhaus 4y ago
Oh yeah, that's the worst. Since logic related to a behavior must be split up across multiple methods, it's really hard to tell if you've actually implemented it correctly. With effects, the setup and teardown is in the same function and can be moved around as a unit.
deckard1 4y ago
I don't know that I agree with that. I recently had to fix a few bugs because some devs forgot, or simply didn't know, that lifecycles still exist. We have reached a period of time where junior devs exist that did not cut their teeth on class components and have no idea of what the lifecycles are. They don't know how rendering works so they either throw up useless memoization everywhere or they don't bother to think of it. The complexity of class components did not vanish. It was only swept under the rug. Take useEffect. It's overloaded to hell and back. It does too much and people continue to struggle with it. Another one, useRef. It's not really for refs, per se. You will end up using it for data other than refs because function instance variables aren't a thing. No one knows when to use useLayoutEffect or useCallback. The fact of the matter is that it's not class components vs. hooks. It's that React's API sucks. It's always sucked. And it continues to suck.
- phailhaus 4y ago
  > I recently had to fix a few bugs because some devs forgot, or simply didn't know, that lifecycles still exist. And then it just stays fixed. You don't have to split up the logic across different lifecycle methods and remember to keep them in sync. They're consolidated into functions that can be trivially pulled out into their own hooks and reused. React is definitely a more low-level framework that requires you to have some familiarity with how the scheduler works, and could benefit from a couple more built-in hooks. But the benefits are undeniable, they make writing and refactoring complex applications an absolute breeze. The fact that you can factor out some state-related behavior into a hook and trivially reuse it is incredible. For example, take state. With hooks, you use useState. A very common pattern is to need to persist it in the URL to enable deep linking. You can literally just replace your useState call with useQueryParam from the use-query-params library [1] and have your component function identically. You just can't do that with class-based components. [1] https://www.npmjs.com/package/use-query-params https://www.npmjs.com/package/use-query-params

theteapot 4y ago

> I'd go as far as to say class-based components are strictly inferior because they force you split your behavior logic across lifecycle methods and are not easily composable. That's not strictly true. You can implement "hooks" on top of a class based components. It's essentially the strategy pattern.