3 ms·
Agreed. I'm a senior dev and I think they're a nightmare to follow, even once you understand how they work. The combinatorial complexity of all the different im
by brundolf 5y ago
Agreed. I'm a senior dev and I think they're a nightmare to follow, even once you understand how they work. The combinatorial complexity of all the different implicit rules is astounding, and there's an entire armory of foot-guns. The lint rules help, but are intrinsically limited by working at a syntax level, not a value level; it's very easy for things to slip past them.
Recently at my job we had a senior engineer (me), a lead engineer, and a junior engineer (all of us familiar with how hooks work), looking at a 10-line hook in the codebase, and we couldn't collectively figure out whether or not it actually did anything without running it to see how it behaved.
If that's not an indictment of hooks, I don't know what is.
I'm no advocate of OOP, but React components are one of the few places where I've had a very good experience using classes
- nouveaux 5y ago"looking at a 10-line hook in the codebase, and we couldn't collectively figure out whether or not it actually did anything without running it to see how it behaved." While hooks do have problems, this could be said about pretty much any programming language or framework, especially when it comes to code that allows for better reusability. In this instance, I suspect it's more of an indictment of the original programmer instead of hooks.
- brundolf 5y agoIt wasn't super elaborate or poorly-written, though it was kind of subtle. It had to do with letting you do something without triggering an update. What we couldn't tell is whether or not it was having the desired effect (or any effect at all) on component updates. But that's just it: the nuanced ways that different hooks do and don't trigger updates are at the heart of what makes them hard to use correctly.