3 ms·
I agree, I think they took a left turn at Albuquerque trying to get into the state management game and honestly saying this as a person that likes FP for everyt
by kls 6y ago
I agree, I think they took a left turn at Albuquerque trying to get into the state management game and honestly saying this as a person that likes FP for everything but UI components, I prefer objects when it comes to modeling UI's it's the one domain in which it fits without impedance mismatch. The problem is UI has state and state and it's management does not fit well with objects as it tends to be event, time and data dependent.
There are some good solutions to state management that are complimentary to React such as XState and it really should be dealt with as a separate concern from a UI component library.
I am concerned that React's object based approach is going to become a second class citizen in lieu of Hooks and that state management is going to get to hardwired to the UI component library.
- brundolf 6y agoExactly. I'm a big believer that state-as-an-implementation-detail is a code smell, but that if your program is fundamentally concerned with state (as UIs nearly always are), you should equip yourself with tools that let you ergonomically manage that state instead of trying to sweep it under the rug and pretend it doesn't exist. Hooks feel like state-denialism to me.
- crooked-v 6y ago> and that state management is going to get to hardwired to the UI component library I don't really see how that's a different state of affairs than class-based components. You just do this if you wanted... const [thisState, setState] = useState({}); ...and its uses would generally be semantically identical to state-based stuff without hooks.