3 ms·
Yeah, hooks totally suck—no question about it. There simply aren't other facets of other front end or back end frameworks that are so widely criticized to the s
by nikkwong 2y ago
Yeah, hooks totally suck—no question about it. There simply aren't other facets of other front end or back end frameworks that are so widely criticized to the same level that hooks are. Which means they're at best controversial, and at worst they're a poor design choice and add mud and confusion to the framework.
I find that hooks are fine when you want to do simple web-app stuff, like fetch from a db, post some data back. But once your effects get more complicated, like using web sockets, items with retries, play or queue async audio clips that have to be state managed with hooks—the house of cards comes crashing down and they are an absolute nightmare to work with.
They're such an anti-pattern that useRef has to be repurposed from a thing that was meant for holding a reference to an HTML element to a new thing that is used to hold state that doesn't trigger a lifecycle update—and there are many paradigms that you can find yourself in where the only path forward is to use refs, along side and inside of your otherwise lifecycle updated hooks. What kind of cluster f*#& is that.
- skydhash 2y agoIt will sound like “you’re holding it wrong” argument. But most issues I heard about hooks is when people don’t isolate their React UI modules from other modules in the application. Instead they use the library/platform api directly in their components which is guaranteed to be a mess. Hooks are way to integrate your UI with the rest of the world, not to manage it. Things like using web sockets, playing audio, etc, should be in external modules which you connect to with hooks, and those modules should be designed with React lifecycle and state in mind. An example is react-query, which does a great job of adapting “fetching from an API” use case to the react world.