Why I detest React Hooks
Tags: react, hooks, javascript
Published: 2020-03-25 23:54:03

React Hooks has been the new hotness ever since it was introduced. I have heard many people discuss about how hooks help them write less code with the same functionality and how it is more performant since everything is now functions. There has also been many articles published online touting, we should ditch classes for functions altogether as less lines of code (LOC) is always better.

What gets me, is how folks think brevity is always better and trying to be clever with their code is somehow the best way to write code. I disagree on both fronts.

Brevity should not be at the expense of clarity as code is written for humans, not machines. Any code you write today will be encountered by you or someone else in your team again in the next 6 months. Being able to still understand the context behind that block of code and make changes confidently, is what well-written code is all about.

I always prefer to be explicit rather than implicit. And React Hooks seems to me like a clever hack. Having converted multiple class based React components to functional components using Hooks, I feel like the function is bloated and violates Single Responsibility Principle (SRP). The hook related code seems to be floating around in the function definition trying to separate the main section of how the component will be rendered, from the function signature.

Compare this to a class based React component where every section is clearly separated into functions that are named after what they represent in the React lifecycle or what action they perform for event handlers. Compare this to the `useEffect` hook which is trying to consolidate mount, update and unmount processes into one. No UI engineer would be confused when they implement lifecycle methods in a class but would certainly be stumped in the beginning when they see the code within `useEffect` being invoked 3 times when they first implement this hook.

Also, trying to adopt the Redux patterns within React seems like moving from being a library to a framework. React is a very good UI library and gives the freedom to use whatever works in other areas. Trying to push towards the redux pattern of using reducers and dispatchers, is a bad move in my books. Not sure if that is because the creator of Redux is now part of the React team. This reminds me of the example of how the React team was pushing for using mixins in the beginning even when a lot of folks had been burnt using it in either other languages or in Javascript. The React team has now denounced the use of mixins.

I hope React will stay as an excellent UI library that is a go-to standard for high-performance UIs and stop trying to be framework. I would love to see more investment in tooling, especially create-react-app and make it more easier to build UIs by standardizing some of conflicting issues that developers have when they start React projects. This is an aspect that I like about the Go programming language where they have published an article about writing Idiomatic Go code to make sure folks follow the same conventions. The tools that Go has take out most of the friction that teams usually have, making any open-source Go code look very much the same.

I look forward to seeing more improvements in the library that lets developers focus more on implementing business features as fast as possible and reduce friction in writing tests by generating test code for most common scenarios like clicking a button, shallow render, etc