6 ms·

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch somethi

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

foota 6y ago
Imo, hooks present an API that is much less difficult to internalize, but maybe holds your hand less? I used react for a few months on a sideish project and had trouble knowing which component method I needed for something, whereas with react now it's all covered by hooks.
awestroke 6y ago
No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.
- batiste 6y ago
  Would it be possible to have a single method on a class that behaves like whatever useEffect is doing?
  - lindskogen 6y ago
    Not in a single method, no. Watch this talk for more details! https://www.youtube.com/watch?v=wXLf18DsV-I https://www.youtube.com/watch?v=wXLf18DsV-I
    - batiste 6y ago
      Well, I did something a bit similar my own language: https://github.com/batiste/blop-language/commit/90e7704e125ffb3c1fe6b4de2446680d3819ab7e https://github.com/batiste/blop-language/commit/90e7704e125f... Not sure where classes are an issue with doing anything like this
- TechBro8615 6y ago
  Adding to this, hooks make it much easier to pull related state management code out of the component. They help make state logic just as composable as UI logic.
fabian2k 6y ago
My superficial understanding is that React components as classes are far more complicated than they might seem at first. You're not in control of creating the class instances, rendering them or destroying them. React is in control of that. The constructor is the wrong place for data fetching in React class components as far as I remember anyway. I don't remember the exact reason, but it always has been somewhat non-obvious and you always needed to understand the React lifecycle to avoid bugs in that kind of code.
ng12 6y ago
> And anyone who has used classes in Java or other languages would feel at home. Not really because there's nothing object oriented about React.Component. It's just a wrapper for a function implemented as a class.
- cmckn 6y ago
  THIS is what I wish I knew about React. As a Java user, I made incredibly wrong and damaging assumptions because "classes, I know what these are"! I still can't make heads or tails of hooks, but in due time!
deviantfero 6y ago
I've worked with both extensively, hooks are way easier to grasp, they allow you to avoid numerous ifs and comparing manually to previous states, you can separate actions according to what properties you're listening changes on, which would be cobbled together in a traditional life-cycle method, and the best part? They can be reused between components
Bahamut 6y ago
In my 1.5 years or so of using hooks, I'm finding components with hooks subtly more buggy than their class counterparts - there are a lot of gotchas with that dependency array for hooks, I have encountered nasty bugs both with explicitly declaring all of the dependencies in the array and declaring less than them. It is much easier to accidentally create infinite loops with useEffect that you would never create with class components, and some of the code you write turns out to be more verbose and less expressive, such as when trying to diff previous and current values of state & needing to create extra state variables with useState for each such value you need to react on. Hooks seem very appealing at first (I lean more FP than OOP in general), but the bugs and slipshod initial rollout out of beta really does not inspire much confidence. Even today I still encounter weird issues.
efdee 6y ago
Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount. Classes in React generate false expectations.
- 7777fps 6y ago
  I liked that model because as an ASP webforms developer the class lifecycle is easy to reason about, like a page lifecycle. In ASP you wouldn't put initialisation code in the page constructor either, it would go in Page_Init, Page_Load, etc. Of course the tooling there made it both easier to put in the right place and harder to edit the page constructor to stick it in the wrong place.
  - efdee 6y ago
    I remember ASP.NET Webforms, and the reason most of the community moved towards MVC-ish frameworks is exactly that most of the time, you ended up shoehorning functionality into different lifecycle methods, which made them much harder to reason about. Most of the time, for anything more complex than just performing the initial databinding, you'd just be looking at the lifecycle chart and trying to figure out which place would be best to put which part of your code. Page_Init? Page_Load? Page_PreRender? I remember the pain of trying to add dynamic controls to a site right in time before ViewState was hydrated but AFTER something else had happened. I agree that for the easiest of use cases, lifecycle methods make sense. But you very quickly leave that comfortable zone and then it just becomes painful and confusing.
    - 7777fps 6y ago
      Don't worry, I'm not espousing lifecycles as a panacea or solution for the modern programmer, I just wanted to share that experience with lifecycle methods meant that I was less tripped up by the pitfalls of react lifecycles. Less so than I've been tripped up by react hooks certainly so it's been a surprise that many here are describing them as being much easier and simpler than classes. Classes had limits and some pitfalls but it's been frustrating that lifecycle methods have been retired and deprecated because sometimes they felt like the natural place to do something.
superice 6y ago
The biggest difference is that the class based components are an older iteration of the API into React, one that lies closer with how React internally works (or worked), but one that is not necessarily useful for writing correctly working components. Say you have a component that renders some data it fetches from the backend, and it received the ID via a prop. In a class based component you might be inclined to write the fetching logic in the componentDidMount or maybe the constructor. However, if you change the ID you feed the component, the component will update instead of being recreated. In the naive class based version it won't refetch the data, and won't behave correctly. With useEffect hooks you don't really care anymore, you can reason about side effects in the same declarative way. You express the fact that fetching new data is a dependency of the prop changing, which holds true both on first render and later on update. The hooks API fixed a handful of these 'mistakes' that were still present in the class based API. I agree that the syntax might look awkward at first, but the hooks API is much better thought out than the class based one. (Some anecdata: almost any component that I rewrote in hooks-style has been halved in number of lines of code, the concepts have been much less spread out over the file. See this tweet for an example: https://twitter.com/threepointone/status/1056594421079261185 https://twitter.com/threepointone/status/1056594421079261185)
conmigo 6y ago
Hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc.. What's maybe the most stupid thing about hooks is that it's overruling the const type declaration: const [count, setCount] = useState(0); You think count is a const? Not with hooks, because hooks are f!@#ng with your core language rules! And all those React + Hooks + Typescript fanatics that live in their type safe bubble fail to even notice it! Even Typescript doesn't complain about it.. Hooks make React a f'ing joke, they've given Dan way too much freedom at FB, IMAO.
- arvinsim 6y ago
  const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change. const is not "constant". In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.
  - conmigo 6y ago
    > It's not for assuring that variable cannot change. Please tell me how you'd change a to 1 in this example: const a = 0;
    - sunaurus 6y ago
      You can't do that. Just like you can't do: const [count, setCount] = useState(0); count = 1; In both cases, const is const. The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React. Here's the exact same scenario without React to show why you're wrong in your original comment: const foo = () => { const bar = getBarFromDatabase(); } Imagine that this is a typical database where values can change, so that every time `foo()` is called, `bar` can have a different value. Do you think that this is a dirty hack that is overruling the const type declaration as well?
cwhiz 6y ago
Class components feel like a spaghetti mess to me whereas Hooks are obvious, straightforward, and clean. I understand that others feel differently but I personally cannot stand working with class components.

foota 6y ago

Imo, hooks present an API that is much less difficult to internalize, but maybe holds your hand less? I used react for a few months on a sideish project and had trouble knowing which component method I needed for something, whereas with react now it's all covered by hooks.

awestroke 6y ago

No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.

batiste 6y ago
Would it be possible to have a single method on a class that behaves like whatever useEffect is doing?
- lindskogen 6y ago
  Not in a single method, no. Watch this talk for more details! https://www.youtube.com/watch?v=wXLf18DsV-I https://www.youtube.com/watch?v=wXLf18DsV-I
  - batiste 6y ago
    Well, I did something a bit similar my own language: https://github.com/batiste/blop-language/commit/90e7704e125ffb3c1fe6b4de2446680d3819ab7e https://github.com/batiste/blop-language/commit/90e7704e125f... Not sure where classes are an issue with doing anything like this
TechBro8615 6y ago
Adding to this, hooks make it much easier to pull related state management code out of the component. They help make state logic just as composable as UI logic.

fabian2k 6y ago

My superficial understanding is that React components as classes are far more complicated than they might seem at first. You're not in control of creating the class instances, rendering them or destroying them. React is in control of that. The constructor is the wrong place for data fetching in React class components as far as I remember anyway. I don't remember the exact reason, but it always has been somewhat non-obvious and you always needed to understand the React lifecycle to avoid bugs in that kind of code.

ng12 6y ago

> And anyone who has used classes in Java or other languages would feel at home. Not really because there's nothing object oriented about React.Component. It's just a wrapper for a function implemented as a class.

cmckn 6y ago
THIS is what I wish I knew about React. As a Java user, I made incredibly wrong and damaging assumptions because "classes, I know what these are"! I still can't make heads or tails of hooks, but in due time!

deviantfero 6y ago

I've worked with both extensively, hooks are way easier to grasp, they allow you to avoid numerous ifs and comparing manually to previous states, you can separate actions according to what properties you're listening changes on, which would be cobbled together in a traditional life-cycle method, and the best part? They can be reused between components

Bahamut 6y ago

In my 1.5 years or so of using hooks, I'm finding components with hooks subtly more buggy than their class counterparts - there are a lot of gotchas with that dependency array for hooks, I have encountered nasty bugs both with explicitly declaring all of the dependencies in the array and declaring less than them. It is much easier to accidentally create infinite loops with useEffect that you would never create with class components, and some of the code you write turns out to be more verbose and less expressive, such as when trying to diff previous and current values of state & needing to create extra state variables with useState for each such value you need to react on. Hooks seem very appealing at first (I lean more FP than OOP in general), but the bugs and slipshod initial rollout out of beta really does not inspire much confidence. Even today I still encounter weird issues.

efdee 6y ago

Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount. Classes in React generate false expectations.

7777fps 6y ago
I liked that model because as an ASP webforms developer the class lifecycle is easy to reason about, like a page lifecycle. In ASP you wouldn't put initialisation code in the page constructor either, it would go in Page_Init, Page_Load, etc. Of course the tooling there made it both easier to put in the right place and harder to edit the page constructor to stick it in the wrong place.
- efdee 6y ago
  I remember ASP.NET Webforms, and the reason most of the community moved towards MVC-ish frameworks is exactly that most of the time, you ended up shoehorning functionality into different lifecycle methods, which made them much harder to reason about. Most of the time, for anything more complex than just performing the initial databinding, you'd just be looking at the lifecycle chart and trying to figure out which place would be best to put which part of your code. Page_Init? Page_Load? Page_PreRender? I remember the pain of trying to add dynamic controls to a site right in time before ViewState was hydrated but AFTER something else had happened. I agree that for the easiest of use cases, lifecycle methods make sense. But you very quickly leave that comfortable zone and then it just becomes painful and confusing.
  - 7777fps 6y ago
    Don't worry, I'm not espousing lifecycles as a panacea or solution for the modern programmer, I just wanted to share that experience with lifecycle methods meant that I was less tripped up by the pitfalls of react lifecycles. Less so than I've been tripped up by react hooks certainly so it's been a surprise that many here are describing them as being much easier and simpler than classes. Classes had limits and some pitfalls but it's been frustrating that lifecycle methods have been retired and deprecated because sometimes they felt like the natural place to do something.

superice 6y ago

The biggest difference is that the class based components are an older iteration of the API into React, one that lies closer with how React internally works (or worked), but one that is not necessarily useful for writing correctly working components. Say you have a component that renders some data it fetches from the backend, and it received the ID via a prop. In a class based component you might be inclined to write the fetching logic in the componentDidMount or maybe the constructor. However, if you change the ID you feed the component, the component will update instead of being recreated. In the naive class based version it won't refetch the data, and won't behave correctly. With useEffect hooks you don't really care anymore, you can reason about side effects in the same declarative way. You express the fact that fetching new data is a dependency of the prop changing, which holds true both on first render and later on update. The hooks API fixed a handful of these 'mistakes' that were still present in the class based API. I agree that the syntax might look awkward at first, but the hooks API is much better thought out than the class based one. (Some anecdata: almost any component that I rewrote in hooks-style has been halved in number of lines of code, the concepts have been much less spread out over the file. See this tweet for an example: https://twitter.com/threepointone/status/1056594421079261185 https://twitter.com/threepointone/status/1056594421079261185)

conmigo 6y ago

Hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc.. What's maybe the most stupid thing about hooks is that it's overruling the const type declaration: const [count, setCount] = useState(0); You think count is a const? Not with hooks, because hooks are f!@#ng with your core language rules! And all those React + Hooks + Typescript fanatics that live in their type safe bubble fail to even notice it! Even Typescript doesn't complain about it.. Hooks make React a f'ing joke, they've given Dan way too much freedom at FB, IMAO.

arvinsim 6y ago
const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change. const is not "constant". In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.
- conmigo 6y ago
  > It's not for assuring that variable cannot change. Please tell me how you'd change a to 1 in this example: const a = 0;
  - sunaurus 6y ago
    You can't do that. Just like you can't do: const [count, setCount] = useState(0); count = 1; In both cases, const is const. The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React. Here's the exact same scenario without React to show why you're wrong in your original comment: const foo = () => { const bar = getBarFromDatabase(); } Imagine that this is a typical database where values can change, so that every time `foo()` is called, `bar` can have a different value. Do you think that this is a dirty hack that is overruling the const type declaration as well?

cwhiz 6y ago

Class components feel like a spaghetti mess to me whereas Hooks are obvious, straightforward, and clean. I understand that others feel differently but I personally cannot stand working with class components.