|
|
|
|
|
|
by nightski
1551 days ago
|
|
|
We can just agree to disagree then. I'd find libraries all the time on github which had class components using state in weird ways you wouldn't expect. It sounds like your org could use some simple guiding principles and code reviews. You seem experienced, this shouldn't be a big problem. Maybe help guide your junior devs? |
|
|
There's power there, and I absolutely agree that hooks do a better job of making for re-usable code than HoCs, I just think that the general level of understanding for them is low, and most devs do a really poor job reasoning about them (and in generally - I find they're basically impossible to reason about in isolation).
I see people do things like wrap everything in useMemo and useCallback, or pass complex objects to useEffect as deps, or fail to understand that making the output of useState the dependency of a useEffect hook that happens to call the corresponding setState function is a recipe for lockups, or any number of other fairly simple mistakes.
Plus... tools like redux strongly encourage destructuring semantics, and destructuring for hooks is absolutely the wrong thing (for the same reason - equality and identity checks). But then you're in a conversation about object identity and memory locations with a dev who has never encountered a pointer in their life, who's 6 months out of a bootcamp, and whose eyes are glazing over further and further with every word out of your mouth.
Worse - hooks can give you a loaded gun if you expect all the environments your code runs in to act like a browser (see my useLocation example with JSDom). Works a-ok when tested in a browser. Will even work nicely for the specific tests you might write for your component (since folks generally mock their hooks) but will absolutely foot-gun you if another spec calls the real hook. Happens to eat up a boatload of CI cpu usage and time as well.