4 ms·

It is definitely possible but there’s so many more places you could make a mistake if each custom Hook has to do bookkeeping like this. I don't know if I could

It is definitely possible but there’s so many more places you could make a mistake if each custom Hook has to do bookkeeping like this. I don't know if I could write or extend the code you wrote without making quite a few mistakes in the process. By comparison, I find following a rule like "calls should be static" much simpler. My post does mention that we care about copy paste experience: >Code passing non-unique or badly composed keys would accidentally work until a Hook is called multiple times or clashes with another Hook. Worse, if it’s meant to be conditional (we’re trying to “fix” the unconditional call requirement, right?), we might not even encounter the clashes until later. >Remembering to pass keys through all layers of custom Hooks seems fragile enough that we’d want to lint for that. They would add extra work at runtime (don’t forget they’d need to serve as keys), and each of them is a paper cut for bundle size. But if we have to lint anyway, what problem did we solve? I later go into why allowing conditional declarations of state or effects isn’t even particularly useful or desirable because the semantics are too confusing. So I do think I kind of addressed that.

thomasfoster96 8y ago
> It is definitely possible but there’s so many more places you could make a mistake if each custom Hook has to do bookkeeping like this. I don't know if I could write or extend the code you wrote without making quite a few mistakes in the process. By comparison, I find following a rule like "calls should be static" much simpler. The book keeping could be moved into a couple of utility functions - it’d be largely the same for most custom hooks. I’m also not sure relying on a linter is necessarily going to make static call Hooks simpler. Poorly written hooks are going to be buggy whether they’re Symbol keyed or not. I think that one of the big disadvantages of static call Hooks would seem to be that incorrect conditional usage could still accidentally work. > My post does mention that we care about copy paste experience I think I misunderstood that section when I first read it - it makes sense now. I’m not convinced it’s a huge win though. > I later go into why allowing conditional declarations of state or effects isn’t even particularly useful or desirable because the semantics are too confusing. We’ll have to agree to disagree - while I’m not eagerly wanting to use Hooks in conditionals, I dont think the semantics are that confusing.

thomasfoster96 8y ago

> It is definitely possible but there’s so many more places you could make a mistake if each custom Hook has to do bookkeeping like this. I don't know if I could write or extend the code you wrote without making quite a few mistakes in the process. By comparison, I find following a rule like "calls should be static" much simpler. The book keeping could be moved into a couple of utility functions - it’d be largely the same for most custom hooks. I’m also not sure relying on a linter is necessarily going to make static call Hooks simpler. Poorly written hooks are going to be buggy whether they’re Symbol keyed or not. I think that one of the big disadvantages of static call Hooks would seem to be that incorrect conditional usage could still accidentally work. > My post does mention that we care about copy paste experience I think I misunderstood that section when I first read it - it makes sense now. I’m not convinced it’s a huge win though. > I later go into why allowing conditional declarations of state or effects isn’t even particularly useful or desirable because the semantics are too confusing. We’ll have to agree to disagree - while I’m not eagerly wanting to use Hooks in conditionals, I dont think the semantics are that confusing.