3 ms·
but you introduce the danger of relying on an api that determines your state based on the order of function calls. if you accidentally take an api that pretends
by snek 8y ago
but you introduce the danger of relying on an api that determines your state based on the order of function calls. if you accidentally take an api that pretends to work based on call site and use it in a loop or callback everything falls apart.
- littlecranky67 8y agoOnly the order of the hook function calls is tracked. The "danger" of 3rd party APIs is a theoretical one, as in most cases you would not put hook function anywhere else except the first level inside the functional component - not into callbacks or whatnot of 3rd party libraries.
- sorahn 8y agoIt only relies on that order between renders. It’s really a non issue. I just spend the last month building a new chunk of our app in hooks to try them out, and it’s really nice to be able to wrap up shared stateful logic without HoCs. A bunch of the HoCs in this app take a “propKey” param, because the HoCs are all stacked on top of each other, and prop collisions happened frequently. Also, it’s a gigantic pain to use TypeScript and “compose”.
- williamdclt 8y agoit’s really nice to be able to wrap up shared stateful logic without HoCs agreed. I loved HOCs for the composibility, abused them and very rarely encountered prop collision, but TS (or Flow) made them a massive pain
- tlrobinson 8y agoIIRC this is easily preventable using the ESLint rule.