13 ms·

I don't understand the hate against class based components. React class-based components are dead simple to understand.

• s_y_n_t_a_x 7y ago
  Nothing is simpler than a function. Easier to write, debug, and test. * Removed "pure" to make my main point clear.
  • RussianCow 7y ago
    But functions that use hooks aren't pure because hooks break referential transparency.
  • istoica 7y ago
    How are your functions pure if inside them you call `useEffect`, `useState` ? Where is pureness when at first look they generate side effects, or am I missing something ?
    • s_y_n_t_a_x 7y ago
      Not all functions needs hooks, not all hooks break pureness. But my point was functions are simpler in all those scenarios, pure or not. Edited my comment to reflect that.
      • csande17 7y ago
        > not all hooks break pureness Sure, if you define a function called useWhatever that doesn't actually call any hooks, that might be a pure function. But the restrictions described in https://reactjs.org/docs/hooks-rules.html https://reactjs.org/docs/hooks-rules.html are not restrictions that pure functions have.
  • shantly 7y ago
    Simplicity does not necessarily imply clarity.
• kybishop 7y ago
  Have you seen the ReactConf talk on hooks? [1] It's absolutely worth the watch, even if you're somewhat familiar with hooks. They go through the pitfalls of class-based components and how hooks solve them. It more-or-less boils down to: 1. class-based components force your lifecycle logic to live in disparate locations. 2. Class-based hooks are obtuse with hidden gotchas whereas pure functions tell you exactly what they're doing. 3. A whole class of unergenomic solutions disappears when you use hooks. [1] https://www.youtube.com/watch?v=dpw9EHDh2bM https://www.youtube.com/watch?v=dpw9EHDh2bM
  • csande17 7y ago
    I'd argue that hooks didn't really make anything better, they just replaced the pitfalls with different obtuse pitfalls and unergonomic solutions. Hooks have their share of weird issues; they explode if they're called in a different order/number from how they were called the first time the component rendered (making them not at all pure functions), and it's super easy to screw up the dependency array to useMemo/useCallback (so either your hook is useless and re-installs the event handler on every render, or you get stupid "the callback had a stale copy of the state" bugs not possible with class-components). I've also seen my fair share of situations where what would have been a this.setState with a callback becomes a tangled mess of useStates and useEffects, or someone bends over backwards to try and avoid re-installing an event handler every time one of the props or state variables it uses changes.
    • aidos 7y ago
      I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again. I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.
      • tracker1 7y ago
        I don't quite get the obsession with the order of hooks... You call all the hooks in your component function and don't optionally do so. In the end, if you're optionally calling different hooks differently in the same component, you're probably doing something wrong, and/or they should be separate components.
• davedx 7y ago
  It's not classes themselves, it's the lifecycle methods, the constructor, this, state, and it all interacts. Hooks let you do more or less the same thing, but IMHO with a simpler and clearer API. You have more control too. Look at the parameters to useState to see what I mean.
  • stickfigure 7y ago
    I feel like there is an alternative world that we aren't seeing, where instead of changing the paradigm, the react team redesigned the class API instead. The class API lifecycle methods are kind of a mess, and useEffect() seems like a more convenient abstraction. But I could imagine replacing the lifecycle methods with hooks that are added at object construction and get similar benefits. I wonder if the problem is not so much classes, but just the API that happened to evolve.