On Hooks

Jake Houston
2 min readAug 6, 2021

I learned React hooks almost accidentally. I attended an optional lecture on hooks, but never completed a lab where I was able to practice one. Instead, I watched five or six hours of project walkthroughs by my cohort lead, where she used them instead of traditional state. I was enormously confused after watching the lecture that introduced me to hooks, but after seeing them in action and beginning to use them myself, I can’t imagine using React without them, mainly because they give you a lot less to think about.

First, there’s no excuse to write a class component anymore. This is a huge deal, because it means that using state isn’t dependent on what kind of component you’ve written, i.e., you’ll never have to write a function component, find out later that you have to use state, and be forced to change it to a class component. When I realized this, my React code became all arrow functions, all the time. Every component was automatically an arrow function, and that was that; I no longer had to put any thought into it.

Getting rid of classes also means not having to deal with this. I never found this to be immensely confusing, but I can’t speak for anyone who works as a frontend developer. Besides, it goes without saying that it’s easier to not have to type it.

But the biggest advantage of hooks for me was how much more expressive they made my code. One of the inconveniences of using state in class components was accounting for it as an object, one that might have multiple key/value pairs. In earlier Flatiron projects, I always felt confused about when I needed to use the spread operator (…) when setting state, and when this was unnecessary. Take my last project, for example, where I would set the boolean value “watched” of a TV show object to true. What would you rather write: A,

this.setState({ ..., watched: true })

or B:

setWatched(true)

To me, it seems pretty obvious. By looking at the function itself, it’s quickly apparent which aspect of state I’m changing; no need to take a look inside the actual object, specify the key/value pair I need to address, and remember the spread operator so that I don’t completely overwrite the state object. Furthermore, when I need to access the part of state which stores whether the TV show has been watched, instead of having to write

this.state.watched

I can now just write

watched

because that’s how I defined it at the top of the component.

My understanding of hooks is pretty basic, so I’ve left out some of the more meaningful reasons why many coders prefer them, such as the fact that you can write your own, or that they make lifestyle methods a lot more intuitive. But I do know that as a novice coder with minimal knowledge of how to modify objects and navigate within a class, hooks were a world of difference from traditional state.

--

--