3 ms·

> 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 th

> 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 ago
The 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 ago
They 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 ago
  I 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.

acemarke 7y ago

The 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 ago

They 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 ago
I 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.