Dropping class components for hooks

When I initially learned React, nearly all of my components were class components simply because it was what I found “easier.” We had recently learned OOP in JavaScript and “this” was fresh in my mind.

My subsequent React projects were a hodgepodge of class components with functional components and hooks sprinkled in. The problem was that I didn’t fully understand why to use one over the other. I simply knew hooks are the future, so I should get to using them.

For my next small project, I made it a goal to only write functional components and to learn the reasons why this is now considered by many to be the best practice.

Going through React’s documentation closely, they outline clearly many of the reasons for adopting hooks. This, especially, stood out to me as a novice.

“In addition to making code reuse and code organization more difficult, we’ve found that classes can be a large barrier to learning React. You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers. Without unstable syntax proposals, the code is very verbose. People can understand props, state, and top-down data flow perfectly well but still struggle with classes. The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers.”

This statement is very interesting because, while it recognizes that the topic is still certainly up for debate in some circles regarding what’s best, they acknowledge that the use of class based components requires some tricky bits that newer developers (or those coming from another language) might find a hindrance to learning.

While I found a bit of a learning curve to adopting the updated syntax, particularly in the critical cases of useEffect and useState, ultimately my code became more readable and DRY.

Overall, I found that I wrote less code. There is no need to extend from React.Component. As stated above, you can drop the ever-present “this.” You can also say goodbye to “bind,” “super,” and “constructor.”

You can simply write the component as you would write any other function.

For example, here is a bit of code from an earlier project from a class component

class MyMovies extends React.Component {

state = {

favorites: [],

reviews: [],

iconShown: false

}

Now this isn’t as verbose as it could be or had been previously — I’m not using constructor and bind — I can make this a functional component and my state is defined as such:

const [favorites, setFavorites] = useState([])

const [reviews, setReviews] = useState([])

const [iconShow, setIconShown] = useState(false)

Now, there isn’t a huge difference here, but the updated version using hooks is cleaner and more intuitive.

Another important point is that “Hooks allow you to reuse stateful logic without changing your component hierarchy.” And we know this is extra important since this statement is bold in the React docs.

You can simplify your components by breaking them into smaller pieces since you are no longer reliant on lifecycle methods like componentDidMount() or componentDidUpdate().

Now, you can have a component that does the work of fetching, for example, without having to tie in a number of other functions and states which might have been otherwise important to a class component but unrelated to the fetch itself. This lends itself again to the idea that hooks are more readable. There might be more components, but the logic and functionality of each will be less bulky when written in this manner.

You can keep your code more DRY by avoiding lifecycle methods altogether, as much of the same logic must be included from component to component to maintain their functionality.

These are the main benefits, as I see them, of turning away from class components and embracing hooks all the time. Also, big shoutout to reading the docs closely.