7 ms·

Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity. Yet then i see people composing t

Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity. Yet then i see people composing together dozens of various hooks and HoC's to achieve the same balance is beyond confusing. Recently i was assigned a PR for a component (a login form) i wrote about a two years ago which was a whole 300 lines. The person who wrote the PR also took the time to make it "functional", which has now resulted in it being split into almost a dozen different files. I don't find this cleaner or easier to understand at all. Current team i am on uses MobX, and Typescript for our app and frankly it is painfully simple, and yet people keep arguing that we should drop mobx, and switch to hooks and i don't see any benefit.

d357r0y3r 8y ago
mobx-react-lite (supported by the main mobx team) uses hooks under the hood, but extends mobx-react behavior to SFCs. I don't think it creates any additional boilerplate and it aligns with the direction React is going.
- Azeralthefallen 8y ago
  Unfortunately to me examples like this looks like you are trying to fit a square peg into a round hole and are twisting something to fit reacts new functional direction.: https://github.com/mobxjs/mobx-react-lite#useobservabletinitialvalue-t-t https://github.com/mobxjs/mobx-react-lite#useobservabletinit...
underwater 8y ago
Are you using Storybook or a similar system? I've got a lot of value in defining my application in decoupled components when I can verify the implementation of each part in isolation.
- Azeralthefallen 8y ago
  We write tests to verify if things are working correctly using Cypress + Mocha. We have simple unit tests for validating basic functionality and extensive integration tests. We typically have a set of tests per feature. The problem i have noticed is that people say "well it works in isolation", but on integration with other components it doesn't work properly. Unfortunately this is a huge problem i find, and frankly the idea of numerous shared hooks and ensuring they are side affect free is very painful.
kabes 8y ago
One part of the functional promise seems to be that if every piece of functionality is small, isolated and easy to understand that the whole of the application becomes easy to understand. However, I would agree that I often find the opposite to be true when everything is scattered around in mini functions over hundreds of files.
- arkh 8y ago
  > One part of the functional promise seems to be that if every piece of functionality is small, isolated and easy to understand that the whole of the application becomes easy to understand. This part is wrong. Your huge components are made of what? Small things. Isolating all those small things just let you add more boilerplate and mental load when trying to debug. To reduce complexity you have to remove code, not move it around.
  - danabramov 8y ago
    I don’t think we promote isolating every little thing. That would indeed be counterproductive. It’s more about being able to reuse some stateful logic between components. That’s the point of custom Hooks. There are pretty cool libraries existing already. For example React Spring takes advantage of that programming model for animations: https://www.react-spring.io/docs/hooks/use-spring https://www.react-spring.io/docs/hooks/use-spring I tried to explain the motivation for Hooks here: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-... Hope it helps.
  - lugg 8y ago
    This whole thread is wrong. Nobody said you had to split the functions off into a bazillion files that's just stupid. Youre taking the worst part of enterprisey OO culture and ruining the best part of functional. And no, you do not need to remove code to reduce complexity you're mistaking correlation for causation. Boilerplate may occur in the short term during a refactor to pure functions but that can eventually be refactored out once things are unshackled enough to be refactored.
Rapzid 8y ago
I'm a bit dumbfounded about the "this" and "class" confusion concern as well. I'm not surprised to hear people have trouble with that per say.. I am surprised a company like Facebook cares about those people. Isn't this the same company that wouldn't hire the homebrew author? I get the sense the only UI people who really know programming work on the React team.
- danabramov 8y ago
  >Isn't this the same company that wouldn't hire the homebrew author? I think you’re confusing it with Google. >I get the sense the only UI people who really know programming work on the React team I haven’t worked in many companies before, but I find my colleagues across the company to be very good UI engineers. Not sure where you got that impression. >I'm a bit dumbfounded about the "this" and "class" confusion concern as well In the grand scheme of things it’s a pretty minor concern (although people do tend to overfocus on it because it’s easiest to explain and discuss). The motivation for Hooks is: * Share reusable stateful and effectful logic between components. Like mixins but without name clashes or the diamond problem. Hooks can be applied more than once, and are instantiated per call. * Colocate related logic instead of artificially splitting it into lifecycle methods. * Accurately model component as being in multiple states at the same time for concurrency. (Important for future React features.) Closures can do that because they capture specific props and state. Finally there are some difficulties related to optimizing class code at compilation time. Such as inlining and fusing classes together. Functions make this simpler and they also minify better due to safer mangling. All of these motivations can be challenging to explain. So people tend to overfocus on “this”. I also wrote this, let me know if it helps: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-...
  - lugg 8y ago
    > * Share reusable stateful and effectful logic between components. Like mixins but without name clashes or the diamond problem. Hooks can be applied more than once, and are instantiated per call. In the mixins are considered harmful blog the point is made that sharing logic between components is a mistake and you should be using composition to achieve the desired outcome. Why do I need hooks? Is composition considered harmful now? > * Colocate related logic instead of artificially splitting it into lifecycle methods. Nope, all this did was make a mess. If splitting your logic into lifecycle methods was too disjoint there was way more going on in that component than their should have been. All useEffect and useState does is turn pure functions into mud that reads like a class but drops all the syntactic sugar that makes it readible. > * Accurately model component as being in multiple states at the same time for concurrency. (Important for future React features.) Closures can do that because they capture specific props and state. Besides this not making any fucking sense, why don't you call new and leave me out of it? As a user, Why do I need hooks today? > Finally there are some difficulties related to optimizing class code at compilation time. Such as inlining and fusing classes together. Functions make this simpler and they also minify better due to safer mangling. Why do I need hooks?
onion2k 8y ago
Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity. I'm surprised you find it so hard to comprehend what other people think considering how trivial I think it is to understand them. Maybe there's a lesson here.

d357r0y3r 8y ago

mobx-react-lite (supported by the main mobx team) uses hooks under the hood, but extends mobx-react behavior to SFCs. I don't think it creates any additional boilerplate and it aligns with the direction React is going.

Azeralthefallen 8y ago
Unfortunately to me examples like this looks like you are trying to fit a square peg into a round hole and are twisting something to fit reacts new functional direction.: https://github.com/mobxjs/mobx-react-lite#useobservabletinitialvalue-t-t https://github.com/mobxjs/mobx-react-lite#useobservabletinit...

underwater 8y ago

Are you using Storybook or a similar system? I've got a lot of value in defining my application in decoupled components when I can verify the implementation of each part in isolation.

Azeralthefallen 8y ago
We write tests to verify if things are working correctly using Cypress + Mocha. We have simple unit tests for validating basic functionality and extensive integration tests. We typically have a set of tests per feature. The problem i have noticed is that people say "well it works in isolation", but on integration with other components it doesn't work properly. Unfortunately this is a huge problem i find, and frankly the idea of numerous shared hooks and ensuring they are side affect free is very painful.

kabes 8y ago

One part of the functional promise seems to be that if every piece of functionality is small, isolated and easy to understand that the whole of the application becomes easy to understand. However, I would agree that I often find the opposite to be true when everything is scattered around in mini functions over hundreds of files.

arkh 8y ago
> One part of the functional promise seems to be that if every piece of functionality is small, isolated and easy to understand that the whole of the application becomes easy to understand. This part is wrong. Your huge components are made of what? Small things. Isolating all those small things just let you add more boilerplate and mental load when trying to debug. To reduce complexity you have to remove code, not move it around.
- danabramov 8y ago
  I don’t think we promote isolating every little thing. That would indeed be counterproductive. It’s more about being able to reuse some stateful logic between components. That’s the point of custom Hooks. There are pretty cool libraries existing already. For example React Spring takes advantage of that programming model for animations: https://www.react-spring.io/docs/hooks/use-spring https://www.react-spring.io/docs/hooks/use-spring I tried to explain the motivation for Hooks here: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-... Hope it helps.
- lugg 8y ago
  This whole thread is wrong. Nobody said you had to split the functions off into a bazillion files that's just stupid. Youre taking the worst part of enterprisey OO culture and ruining the best part of functional. And no, you do not need to remove code to reduce complexity you're mistaking correlation for causation. Boilerplate may occur in the short term during a refactor to pure functions but that can eventually be refactored out once things are unshackled enough to be refactored.

Rapzid 8y ago

I'm a bit dumbfounded about the "this" and "class" confusion concern as well. I'm not surprised to hear people have trouble with that per say.. I am surprised a company like Facebook cares about those people. Isn't this the same company that wouldn't hire the homebrew author? I get the sense the only UI people who really know programming work on the React team.

danabramov 8y ago
>Isn't this the same company that wouldn't hire the homebrew author? I think you’re confusing it with Google. >I get the sense the only UI people who really know programming work on the React team I haven’t worked in many companies before, but I find my colleagues across the company to be very good UI engineers. Not sure where you got that impression. >I'm a bit dumbfounded about the "this" and "class" confusion concern as well In the grand scheme of things it’s a pretty minor concern (although people do tend to overfocus on it because it’s easiest to explain and discuss). The motivation for Hooks is: * Share reusable stateful and effectful logic between components. Like mixins but without name clashes or the diamond problem. Hooks can be applied more than once, and are instantiated per call. * Colocate related logic instead of artificially splitting it into lifecycle methods. * Accurately model component as being in multiple states at the same time for concurrency. (Important for future React features.) Closures can do that because they capture specific props and state. Finally there are some difficulties related to optimizing class code at compilation time. Such as inlining and fusing classes together. Functions make this simpler and they also minify better due to safer mangling. All of these motivations can be challenging to explain. So people tend to overfocus on “this”. I also wrote this, let me know if it helps: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-...
- lugg 8y ago
  > * Share reusable stateful and effectful logic between components. Like mixins but without name clashes or the diamond problem. Hooks can be applied more than once, and are instantiated per call. In the mixins are considered harmful blog the point is made that sharing logic between components is a mistake and you should be using composition to achieve the desired outcome. Why do I need hooks? Is composition considered harmful now? > * Colocate related logic instead of artificially splitting it into lifecycle methods. Nope, all this did was make a mess. If splitting your logic into lifecycle methods was too disjoint there was way more going on in that component than their should have been. All useEffect and useState does is turn pure functions into mud that reads like a class but drops all the syntactic sugar that makes it readible. > * Accurately model component as being in multiple states at the same time for concurrency. (Important for future React features.) Closures can do that because they capture specific props and state. Besides this not making any fucking sense, why don't you call new and leave me out of it? As a user, Why do I need hooks today? > Finally there are some difficulties related to optimizing class code at compilation time. Such as inlining and fusing classes together. Functions make this simpler and they also minify better due to safer mangling. Why do I need hooks?

onion2k 8y ago

Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity. I'm surprised you find it so hard to comprehend what other people think considering how trivial I think it is to understand them. Maybe there's a lesson here.