10 ms·
Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved. But hooks creates abstractions the dev
by bcheung 7y ago
Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved.
But hooks creates abstractions the developer needs to deal with that never existed before.
Hooks are not functional because they break referential transparency of functions.
You have to track dependencies manually and hooks are more difficult than they need to be for the "componentDidMount" equivalent. If you don't get the dependencies just right you end up with things not firing or in infinite loops.
You have to wrap your functions in "useCallback" or "useRef" just so the reference doesn't change and cause infinite loops.
You can't create abstractions where a hook calls another hook. So you end up having to inline a bunch more code into your function rather than outsourcing it into a helper function.
The positional order seems like it would be easy to work around if they allowed you to pass in a key. Not sure why that isn't available.
- bcyn 7y ago> You can't create abstractions where a hook calls another hook. Not sure if I understand you correctly, but isn't this the purpose of custom hooks? You should be able to freely call hooks within other hooks.
- Normal_gaussian 7y agoYou absolutely can create abstractions where a hook calls another hook. It is perhaps the single most useful change hooks have given me. Of course you need to follow the same rules in the hook (always call every hook it calls, in the same order, so you don't mess up the order above).
- bcheung 7y agoNot inside of useEffect.
- Normal_gaussian 7y agoYes, you're right with that. Its curious that I haven't found that to be a pain point.
- shantly 7y ago> The positional order seems like it would be easy to work around if they allowed you to pass in a key. Not sure why that isn't available. IIRC it's because they implemented their own method lookup table (!) to associate with the Component object (!) but as a FIFO queue, more or less. I assume either for ideological (that's how they wanted it to work) reasons or because they (probably correctly) reasoned that loading down React apps with more strings at such a basic level would risk performance/memory problems. Plus if they did that then it'd really look like a method lookup table and be more obviously Rube-Goldbergian than it already is.
- acemarke 7y agoThe primary concern was transparent composition and enabling "custom hooks". All of the "named/keyed hooks" proposals from the community failed that test. Custom hooks naturally fall out of the current implementation. Technically, React doesn't even know that custom hooks exist - it just knows that more of the primitive hooks are being called inside your own component. If you've got time, skimming the original React Hooks RFC https://github.com/reactjs/rfcs/pull/68 https://github.com/reactjs/rfcs/pull/68 ) is informative (and admittedly difficult, because there's hundreds of similar comments).
- bcheung 7y agoThey can make the string part optional. Variables and symbol tables have been staples of programming languages and compilers for ages now. It's a very standard pattern. Nothing Rube-Goldberg about it. But React has deviated so far from both the OOP, FP, and traditional programming paradigms that now it kind of feels like hacks are needed to compensate for hacks.
- shantly 7y agoI mean at the point you're writing a symbol table and associating it with an object so you can figure out which method to call in its context, probably it occurs to you that you're entirely re-creating a feature the language already has (but slower and worse) rather than just mostly doing so, as they are now.