Before I get started, I’d like to express how grateful I am for all of the work that the React team has put in over the years. They’ve created an awesome framework that in many ways was my introduction to the modern web. They have paved the path for me to believe the ideas I’m about to present and I would not have arrived at these conclusions without their ingenuity.

In the following paragraphs, I would like to walk step by step through my observed shortcomings of hooks and propose an alternative API that is as capable, but with fewer caveats. I’ll say right now that this alternative API is a bit verbose, but it is less computationally wasteful, more conceptually accurate, and it’s framework agnostic 🎉.

Hooks Problem #1: Attached during render

As a general rule of design, I’ve found that we should always first try to disallow our users from making mistakes. Only if we’re unable to prevent the user from making a mistake, should we then inform them of the mistake after they’ve made it.

For example, if allowing a user to enter a quantity in an input field, we could allow them to enter alphanumeric characters and then show them an error message if we find an alphabetic character in their input. However, we could provide better UX if we allowed them only to enter numeric characters into the field, which would eliminate the need to check whether they have included alphabetic characters.

React behaves quite similarly.

If we think about hooks conceptually, they are static through the lifetime of a component.

By this I mean that once declared, we cannot remove them from a component or change their position in relation to other hooks. React uses lint rules and will throw errors to try to prevent developers from violating this detail of hooks.

#react #javascript #reactjs #vuejs