4 ms·
Yeah, I started going "well, time to look at the rest of the ecosystem for the Next Thing" with Hooks. Given requirements that meant, to progress, they were go
by handrous 5y ago
Yeah, I started going "well, time to look at the rest of the ecosystem for the Next Thing" with Hooks.
Given requirements that meant, to progress, they were going to need to either:
1) Tell devs that sometimes they would simply have to use classes/objects for some components, because certain performance enhancements or state-management would only be available there, or;
2) Partially re-implement objects with really bizarre declaration syntax, in a language that already has objects—shit, its functions are objects, and maybe it's changed but I read the hooks code when it was added and it was just some FIFO property/method queues, rather than tables, tied to a damn object representing your component in React's core state-machine;
They chose #2.
[EDIT] yes I'm aware that one reason they prominently gave for hooks was that inheritance hierarchies could cause problems in React codebases, but that seems woefully insufficient as a motivation for writing a crippled version of objects/classes that lack the features they had problems with, rather than just telling people "maybe stop hitting yourself?" and continuing to use what the language already provided, which everyone already understood.
- dexwiz 5y agoThe thing that blew my mind was React gave a decent abstraction for externally set values vs internally managed values in props/state. And then the community immediately declared State as evil, and boiled the ocean to replace it. All UIs need state. Yes state is bad in most cases and makes programming harder. No abstracting it into 4 different files doesn't make it any clearer. There was an issue with composition in React. HOC didn't scale very well, and Inheritance is almost always Bad (TM). That said, I do think hooks were an esoteric choice versus a more explicit service registration/DI pattern.