3 ms·

Here’s what I mean: https://gist.github.com/thomasfoster96/c4a20053c747196f027fcd871fc82f03 https://gist.github.com/thomasfoster96/c4a20053c747196f027fc... > A

Here’s what I mean: https://gist.github.com/thomasfoster96/c4a20053c747196f027fcd871fc82f03 https://gist.github.com/thomasfoster96/c4a20053c747196f027fc... > A key design goal is that creating a custom Hook is easy. You should be able to literally copy paste part of your component (e.g. a bunch of useState calls and some event handlers) and call it a day. I'd totally understand that reasoning, because the keyed Hooks are more verbose and would generally require two or three parts of a component to be copy-pasted – but the examples under Flaws #3 and #5 didn't make this clear (to me at least), and I hadn’t seen ‘ease of custom Hook implementation’ cited as an argument against keyed hooks before. I’m really just playing devil’s advocate here, because in my playing around with Hooks I haven’t yet found a case where keyed Hooks are necessary, but I have accidentally put calls to useState() inside a conditional a heap of times. Edit: Flaw #5, not #7

danabramov 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. 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.

danabramov 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. 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.