4 ms·

Agree, "More Stuff to Learn" isn't really a critique of hooks, it's a critique of learning.

nicoburns 6y ago
Yeah, I don't really get this criticism in regards to hooks. I think it took me maybe an hour to learn them. That's basically nothing.
- lucideer 6y ago
  I've never* used hooks and I only got 1 question wrong in the author's Google Forms quiz (would've been 2 wrong, but bullet point 4 had already signposted the object equality gotcha). So there doesn't seem to be a huge amount to learn in hooks as far as I can tell. * I am an experienced React developer but haven't had much opportunity to work with it in the past 2 years.
lhorie 6y ago
TFA addresses this: it qualifies by saying learning is good as long as it's useful outside of whatever narrow scope they appear. The real criticism in that section is that hooks (and e.g. gotchas related to things like useEffect, stale closures, etc) are non-transferrable knowledge.
- lucideer 6y ago
  As others have said, I still don't really think it's applicable because learning hooks takes an hour or two, but to try and address that point: I don't really think the knowledge is non-transferable at all. There's two aspects to learning hooks: 1. Learning the API. This is not a "conceptual" part of learning but rather "this function name does this thing". This is the same with learning any programming API and is almost always non-transferrable (with the minor exception of some open standards, except that varying implementations of them still tend to have quirks). 2. Learning the patterns and concepts around applying that API to problems. As far as I've seen just from TFA examples, they're very widely applicable. Memoization is widespread. Functional style is widespread. The most complex stuff handled by the quoted examples is maintaining state in nested hashtables, which is such a widespread concept that observable/immutable libraries like MobX et al & ImmutableJS et al have been written pretty much focused entirely on this problem space.

Yeah, I don't really get this criticism in regards to hooks. I think it took me maybe an hour to learn them. That's basically nothing.

lucideer 6y ago
I've never* used hooks and I only got 1 question wrong in the author's Google Forms quiz (would've been 2 wrong, but bullet point 4 had already signposted the object equality gotcha). So there doesn't seem to be a huge amount to learn in hooks as far as I can tell. * I am an experienced React developer but haven't had much opportunity to work with it in the past 2 years.

lhorie 6y ago

TFA addresses this: it qualifies by saying learning is good as long as it's useful outside of whatever narrow scope they appear. The real criticism in that section is that hooks (and e.g. gotchas related to things like useEffect, stale closures, etc) are non-transferrable knowledge.

lucideer 6y ago
As others have said, I still don't really think it's applicable because learning hooks takes an hour or two, but to try and address that point: I don't really think the knowledge is non-transferable at all. There's two aspects to learning hooks: 1. Learning the API. This is not a "conceptual" part of learning but rather "this function name does this thing". This is the same with learning any programming API and is almost always non-transferrable (with the minor exception of some open standards, except that varying implementations of them still tend to have quirks). 2. Learning the patterns and concepts around applying that API to problems. As far as I've seen just from TFA examples, they're very widely applicable. Memoization is widespread. Functional style is widespread. The most complex stuff handled by the quoted examples is maintaining state in nested hashtables, which is such a widespread concept that observable/immutable libraries like MobX et al & ImmutableJS et al have been written pretty much focused entirely on this problem space.