DEV Community

Discussion on: The Botched Implementation of useEffect()

Collapse
 
bytebodger profile image
Adam Nathaniel Davis

First, thanks for that link! That package looks kinda awesome.

Second, I'm generally pro-simplification. I think any decent programmer is. But there's a difference between "simplification" versus "we simply removed a whole bunch of the previous functionality". If you take my car, then you hand me back nothing but a steering wheel, I'm not calling that "simplification".

I do understand that any time you move from Paradigm A to Paradigm B, the first reaction is to look for all of the exact tools/features/methods that you used under Paradigm A - and to complain when they're not there. I also understand that, often, Paradigm B isn't just a new feature, but is instead a completely different way of thinking about the problem.

...but thats what a library is supposed to do, abstract the how it works in order to use it with ease, again...

That's basically the crux of my argument. I've been using Hooks quite heavily now for about 6 months. And I've found little about useEffect() that I'd call "ease". It's confusing to remember when useEffect() will be invoked, based on the way in which it's called. It's also woefully incomplete.

It's like the Hooks team took my car, gave me back nothing but a steering wheel, patted themselves on the back, and left me wondering how in the heck I'm supposed to get to the grocery store. Telling me that they abstracted away my car doesn't do me any good. I'm still standing in my garage with nothing but a steering wheel. Telling me that I can just take the bus is not a viable answer. Assuring me that I really don't need a car is not a viable answer.