5 ms·

React 18 is now in beta

8 points by tilt 5y ago

PaulHoule 5y ago
All of those hooks make me wonder if object-based components aren't going to be supported at some point.
- NaughtyShiba 5y ago
  Less or more it’s likely to happen, and could have been expected 2-3 years ago. Especially with https://github.com/facebook/prepack https://github.com/facebook/prepack. They want to eventually ship pre-compiled components rather than React.createElement() to end user
- seattle_spring 5y ago
  Why would they be? There's no reason to use class based components at all, except to support legacy code.
  - wishawa 5y ago
    Concise and simple functional components are often desirable. But class components and OOP allow you to make components that are complex yet generic and reusable. Example from real experience: I had an `InfinityScroller` functional component. The `loadMoreItems` prop signature was a function with ten arguments because different usages require different state data when deciding what to load. I converted the component to class based. `loadMoreItems` became an abstract method. No more overly complicated type signature because I can just access and update `this.state`.
  - colejohnson66 5y ago
    For me, it’s not a technical reason, but the constant churn of new features, while nice and useful, is frustrating. What is “idiomatic” keeps changing. I learned React 3 years ago when class components were the way to have local state. I’ve tried keeping up with all the new features, but if I wasn’t trying, I’d be far out of the loop. Granted, this is more a JavaScript ecosystem complaint, but it applies here.
    - ostenning 5y ago
      Anything stable ultimately gets dethroned so its in every popular framework / library’s interest to continue to attempt to innovate, even if it means superfluous yet highly breaking API changes
  - PaulHoule 5y ago
    I like class based components. I like functional components too when they are appropriate and hooks aren’t involved. I know how to build testable class based components. I dread the idea of modeling the fine behavior of hooks. I like objects as a place to hang event handlers. I hate seeing setState in lambdas inside a render() method. For one thing it gets in the way of rapid scanning of the code to know that somebody didn't slip a rogue setState into the render method (have to look at that punctuation.) Another one is that often the exact same behavior gets bound in four places or very similar behavior is bound in 15 places. I see the hooks as treacherous. On one hand they masquerade as ‘functional’ (will never hear the end of noobs who think they are doing ‘functional programming’) but the order in which the functions are called matters for hooks. Probably some hooks are properly written but I don’t have a lot of faith; I see so many systems in React that are a house of cards and only work by accidents and hooks seems like a great way to keep that tradition going.

8 points by tilt 5y ago

PaulHoule 5y ago

All of those hooks make me wonder if object-based components aren't going to be supported at some point.

NaughtyShiba 5y ago
Less or more it’s likely to happen, and could have been expected 2-3 years ago. Especially with https://github.com/facebook/prepack https://github.com/facebook/prepack. They want to eventually ship pre-compiled components rather than React.createElement() to end user
seattle_spring 5y ago
Why would they be? There's no reason to use class based components at all, except to support legacy code.
- wishawa 5y ago
  Concise and simple functional components are often desirable. But class components and OOP allow you to make components that are complex yet generic and reusable. Example from real experience: I had an `InfinityScroller` functional component. The `loadMoreItems` prop signature was a function with ten arguments because different usages require different state data when deciding what to load. I converted the component to class based. `loadMoreItems` became an abstract method. No more overly complicated type signature because I can just access and update `this.state`.
- colejohnson66 5y ago
  For me, it’s not a technical reason, but the constant churn of new features, while nice and useful, is frustrating. What is “idiomatic” keeps changing. I learned React 3 years ago when class components were the way to have local state. I’ve tried keeping up with all the new features, but if I wasn’t trying, I’d be far out of the loop. Granted, this is more a JavaScript ecosystem complaint, but it applies here.
  - ostenning 5y ago
    Anything stable ultimately gets dethroned so its in every popular framework / library’s interest to continue to attempt to innovate, even if it means superfluous yet highly breaking API changes
- PaulHoule 5y ago
  I like class based components. I like functional components too when they are appropriate and hooks aren’t involved. I know how to build testable class based components. I dread the idea of modeling the fine behavior of hooks. I like objects as a place to hang event handlers. I hate seeing setState in lambdas inside a render() method. For one thing it gets in the way of rapid scanning of the code to know that somebody didn't slip a rogue setState into the render method (have to look at that punctuation.) Another one is that often the exact same behavior gets bound in four places or very similar behavior is bound in 15 places. I see the hooks as treacherous. On one hand they masquerade as ‘functional’ (will never hear the end of noobs who think they are doing ‘functional programming’) but the order in which the functions are called matters for hooks. Probably some hooks are properly written but I don’t have a lot of faith; I see so many systems in React that are a house of cards and only work by accidents and hooks seems like a great way to keep that tradition going.