3 ms·
Re: 'Flaw #6: We Still Need a Linter' (first example): Could the 'primitive' hooks (useState, useEffect, etc) walk up `arguments.callee.caller.arguments.callee
by nihakue 8y ago
Re: 'Flaw #6: We Still Need a Linter' (first example):
Could the 'primitive' hooks (useState, useEffect, etc) walk up `arguments.callee.caller.arguments.callee.caller...` grabbing function names until you hit a React function? Then use the names to create a 'composed' key automatically? It still doesn't solve the problem of a function using the same hook twice in one function, but it might solve the problem of collision across custom hooks.
Example:
function useCount() {
const [count, setState] = useState(0)
return { count, increment: () => setState(count + 1)};
}
function useCountPlusOne() {
const {count: baseCount, increment} = useCount()
return {count: baseCount + 1, increment}
}
function MyHookComponent() {
const { count, increment } = useCountPlusOne()
return ...
}
Would give you a key of
`useState(useCount(useCountPlusOne(MyHookComponent)))` without the end user having to futz around composing the key manually. At this point you could probably even forego the 'use*' convention
It's still pretty magical, but the magic seems more abstracted. In general I've really liked hooks, and I'm willing to put up with the wackiness (although testing them with enzyme is a big PITA right now).
Thanks for the article :)
- WorldMaker 8y agoThere are some big performance implications of using `arguments` (most current JITs heavily deoptimize functions that use `arguments`), and arrow functions in the spec are supposed to throw errors for any attempts to access their `arguments`. It's probably not a good idea for Production code.