3 ms·

The problem is that the hooks seem to be much more restricting than setState. You can `if (condition) this.setState({x: 1})` but you can not with hooks because

The problem is that the hooks seem to be much more restricting than setState. You can `if (condition) this.setState({x: 1})` but you can not with hooks because React keeps track and doesn't allow you to break out of a very narrow usage. Look at the rules from the docs: > Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions. > Only call Hooks from React function components. Don’t call Hooks from regular JavaScript functions. I think this will lead to junior developers to not understand the React framework but to just accept "the way to do things" and do what the docs say, without ever questioning anything.

scq 8y ago
I think those rules only apply to useState and useEffect themselves, and not to the setState function you get back when you call useState.
- DougBTX 8y ago
  Yes, I think you’re right, there are different restrictions on when useState and setState, though it is worrying seeing confusion straight away about it. I wonder about a case where there is an expandable panel in a UI, and when expanded it should fetch then display data from a web service. Easy enough to do with this API by splitting the content of the panel out into a second component, but it is going to be very tempting to wrap that useEffect fetch call in an `if (expanded)` condition. On the other hand, there are lots of positives about this design too, the correctly written code does look very elegant and I can see it solving real problems.
  - trixn 8y ago
    As I understood it you should not opt-in to use state conditionally in your component but you can still conditionally set the state. That means you should not conditionally call `useState` but it is fine to conditionally call the `setState` returned by the `useState`. That is not different to how you would use state in a class based component where you also wouldn't attach a state `this.state = {...}` somewhere in the middle of its lifetime. The component has state from the beginning of its lifetime or it hasn't state at all. There is not such concept as "Now that you are expanded you will transform into a stateful component".
  - tree_of_item 8y ago
    What is worrying about that useState/setState example? The person just didn't read the page properly, it's not an indictment of the API. Maybe give it a month or two before the claims about confusion, this was just someone skimming the page and missing some details.
  - dceddia 8y ago
    I think the recommended pattern if you need a "conditional effect" would be to just move the `if (expanded)` inside the effect instead of wrapping it.
rimunroe 8y ago
I think it's best to treat the various hooks the same as method definitions: you wouldn't conditionally define componentDidUpdate or componentWillUnmount in a class component. Instead, you would conditionally do something within those (always-present) functions. The same applies for these hooks.
- christopherscot 8y ago
  I had this thought as well. Ironic isn’t it, given that the main reason for hooks is that “classes are hard”.
  - rimunroe 8y ago
    I'm unsure what's ironic about it. Hooks feel significantly easier to me than classes in a bunch of dimensions. Classes come with a whole lot of syntax & concepts like constructors, instance vs class properties, autobinding, that are otherwise not used at all in React. They present barriers to optimizing code with compilers, and property names don't get minified. Hooks are Just Functions though. They don't even have to deal with the most confusing aspect of functions in JS: "this"/calling context. You could easily consume them in ES3 by just not using array destructures and function keywords and it would barely get less readable. Contrast this with classes, where new devs are often pushed to learn experimental and often-changing syntax just to avoid the awkwardness of working with the current specification for classes in JS. The following isn't allowed per the spec or any stage 4 proposal, but it's all over intro tutorials so that people don't have to manually bind methods in the constructor. class Foo { handleClick = event => {...} })

scq 8y ago

I think those rules only apply to useState and useEffect themselves, and not to the setState function you get back when you call useState.

DougBTX 8y ago
Yes, I think you’re right, there are different restrictions on when useState and setState, though it is worrying seeing confusion straight away about it. I wonder about a case where there is an expandable panel in a UI, and when expanded it should fetch then display data from a web service. Easy enough to do with this API by splitting the content of the panel out into a second component, but it is going to be very tempting to wrap that useEffect fetch call in an `if (expanded)` condition. On the other hand, there are lots of positives about this design too, the correctly written code does look very elegant and I can see it solving real problems.
- trixn 8y ago
  As I understood it you should not opt-in to use state conditionally in your component but you can still conditionally set the state. That means you should not conditionally call `useState` but it is fine to conditionally call the `setState` returned by the `useState`. That is not different to how you would use state in a class based component where you also wouldn't attach a state `this.state = {...}` somewhere in the middle of its lifetime. The component has state from the beginning of its lifetime or it hasn't state at all. There is not such concept as "Now that you are expanded you will transform into a stateful component".
- tree_of_item 8y ago
  What is worrying about that useState/setState example? The person just didn't read the page properly, it's not an indictment of the API. Maybe give it a month or two before the claims about confusion, this was just someone skimming the page and missing some details.
- dceddia 8y ago
  I think the recommended pattern if you need a "conditional effect" would be to just move the `if (expanded)` inside the effect instead of wrapping it.

rimunroe 8y ago

I think it's best to treat the various hooks the same as method definitions: you wouldn't conditionally define componentDidUpdate or componentWillUnmount in a class component. Instead, you would conditionally do something within those (always-present) functions. The same applies for these hooks.

christopherscot 8y ago
I had this thought as well. Ironic isn’t it, given that the main reason for hooks is that “classes are hard”.
- rimunroe 8y ago
  I'm unsure what's ironic about it. Hooks feel significantly easier to me than classes in a bunch of dimensions. Classes come with a whole lot of syntax & concepts like constructors, instance vs class properties, autobinding, that are otherwise not used at all in React. They present barriers to optimizing code with compilers, and property names don't get minified. Hooks are Just Functions though. They don't even have to deal with the most confusing aspect of functions in JS: "this"/calling context. You could easily consume them in ES3 by just not using array destructures and function keywords and it would barely get less readable. Contrast this with classes, where new devs are often pushed to learn experimental and often-changing syntax just to avoid the awkwardness of working with the current specification for classes in JS. The following isn't allowed per the spec or any stage 4 proposal, but it's all over intro tutorials so that people don't have to manually bind methods in the constructor. class Foo { handleClick = event => {...} })