3 ms·

> But as we have seen today, the base class setState() implementation has been an illusion all along. It doesn’t do anything except forwarding the call to the c

> But as we have seen today, the base class setState() implementation has been an illusion all along. It doesn’t do anything except forwarding the call to the current renderer. And useState Hook does exactly the same thing. This is worded a bit weirdly. The fact that there is some indirection and the meat of the `setState` is in the renderer and not in the component doesn't really make `setState` an illusion. A call to `setState` still does exactly what we thought it did.

maaaats 8y ago
> > And useState Hook does exactly the same thing. Except it does more bookkeeping behind the scenes to know which state you want (since you're not passing in an identificator). Wonder why they chose that solution, as it's just more magic for really no gain, and it will give you funny bugs if you call it in a loop or in a condition.
- danabramov 8y ago
  I wrote about why here: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-... (TLDR: that makes custom Hooks very powerful)
  - petilon 8y ago
    From hooks documentation: If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. React applications using the MVC model don't have this problem. In MVC Components just handle rendering. Stateful logic go into controllers. I think React is getting unnecessarily complicated because of the "everything is a component" model. I strongly recommend comparing/contrasting this with MVC model. Here's an MVC router that works well with React: https://github.com/edman3d/mvc-router https://github.com/edman3d/mvc-router It is a pity that React was originally designed to be the V in MVC, and then the developer community took it in a different direction.
    - danabramov 8y ago
      Did you read the linked article? I think you’re overfocusing on one argument and might be missing the bigger picture. In my experience MVC doesn’t really help with the problems that extracting and reusing custom Hooks attempts to solve. Controllers aren’t composable in the way functions are. (An alternative take on this is that Hooks are controller-ish.)
      - petilon 8y ago
        From the linked article: Components are more powerful, but they have to render some UI. This makes them inconvenient for sharing non-visual logic. This is how we end up with complex patterns like render props and higher-order components. But this is a problem with how some applications are using React, where they make everything a React component. You don't need to make everything a React component. In the MVC model only things that put stuff on the screen need to be React components. You are saying Hooks are better than controllers--and maybe they are. But when the problem is stated as in the above paragraph, then it is not obvious that Hooks are the solution. Maybe the problem should be stated better.
danabramov 8y ago
Maybe I need to rephrase. I meant that many people imagine Component class as being the meat of the codebase, heavily operating on `this` and updating things on it. Similarly folks often imagine `this.state` being the source of truth (and thus Hooks seem too ephemeral). But both of them are indirections to the same place elsewhere. And state for both of them is kept in the renderer. For classes it’s synced to `this.state` at the last moment so you can read it but `this` is not the source of truth.
- sfvisser 8y ago
  > I meant that many people imagine Component class as being the meat of the codebase, heavily operating on `this` and updating things on it. Yeah maybe. Even when it's not true it is still a valid way of looking at it I think. In the abstract sense that's what's being modelled here with the API, right? The fact that the internals are different is an implementation detail. Of course, it might be an interesting detail, hence your blogpost. > Similarly folks often imagine `this.state` being the source of truth (and thus Hooks seem too ephemeral). I still don't understand why this is though. In some of my projects I actually manage my own local state on the component class (without this.state/setState) and auto `forceRender` when something changes. In those cases my state is super sync and everything works fine. With the additional benefit of my local domain logic being modular: I can read my state after having updated it and it works like expected. So know I can write multiple methods dealing with my local state and compose them freely — like actual OO. I understand the hooks world is a different story, but in the compat component world it all seemed just fine. Why doesn't react use `this.state` as the source of truth, or update it more aggressively so it at least looks like the source of truth to me? Perf reasons? Is it worth it?

maaaats 8y ago

> > And useState Hook does exactly the same thing. Except it does more bookkeeping behind the scenes to know which state you want (since you're not passing in an identificator). Wonder why they chose that solution, as it's just more magic for really no gain, and it will give you funny bugs if you call it in a loop or in a condition.

danabramov 8y ago
I wrote about why here: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-... (TLDR: that makes custom Hooks very powerful)
- petilon 8y ago
  From hooks documentation: If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. React applications using the MVC model don't have this problem. In MVC Components just handle rendering. Stateful logic go into controllers. I think React is getting unnecessarily complicated because of the "everything is a component" model. I strongly recommend comparing/contrasting this with MVC model. Here's an MVC router that works well with React: https://github.com/edman3d/mvc-router https://github.com/edman3d/mvc-router It is a pity that React was originally designed to be the V in MVC, and then the developer community took it in a different direction.
  - danabramov 8y ago
    Did you read the linked article? I think you’re overfocusing on one argument and might be missing the bigger picture. In my experience MVC doesn’t really help with the problems that extracting and reusing custom Hooks attempts to solve. Controllers aren’t composable in the way functions are. (An alternative take on this is that Hooks are controller-ish.)
    - petilon 8y ago
      From the linked article: Components are more powerful, but they have to render some UI. This makes them inconvenient for sharing non-visual logic. This is how we end up with complex patterns like render props and higher-order components. But this is a problem with how some applications are using React, where they make everything a React component. You don't need to make everything a React component. In the MVC model only things that put stuff on the screen need to be React components. You are saying Hooks are better than controllers--and maybe they are. But when the problem is stated as in the above paragraph, then it is not obvious that Hooks are the solution. Maybe the problem should be stated better.

danabramov 8y ago

Maybe I need to rephrase. I meant that many people imagine Component class as being the meat of the codebase, heavily operating on `this` and updating things on it. Similarly folks often imagine `this.state` being the source of truth (and thus Hooks seem too ephemeral). But both of them are indirections to the same place elsewhere. And state for both of them is kept in the renderer. For classes it’s synced to `this.state` at the last moment so you can read it but `this` is not the source of truth.

sfvisser 8y ago
> I meant that many people imagine Component class as being the meat of the codebase, heavily operating on `this` and updating things on it. Yeah maybe. Even when it's not true it is still a valid way of looking at it I think. In the abstract sense that's what's being modelled here with the API, right? The fact that the internals are different is an implementation detail. Of course, it might be an interesting detail, hence your blogpost. > Similarly folks often imagine `this.state` being the source of truth (and thus Hooks seem too ephemeral). I still don't understand why this is though. In some of my projects I actually manage my own local state on the component class (without this.state/setState) and auto `forceRender` when something changes. In those cases my state is super sync and everything works fine. With the additional benefit of my local domain logic being modular: I can read my state after having updated it and it works like expected. So know I can write multiple methods dealing with my local state and compose them freely — like actual OO. I understand the hooks world is a different story, but in the compat component world it all seemed just fine. Why doesn't react use `this.state` as the source of truth, or update it more aggressively so it at least looks like the source of truth to me? Perf reasons? Is it worth it?