React Hooks: useState and useEffect - The Matrix Awakens

The Quest Begins (The "Why")

Honestly, I still remember the first time I tried to make a simple counter with a class component. I had this.state, this.setState, componentDidMount, componentDidUpdate, and a weird feeling that every time I clicked the button the console would spam logs like I was stuck in a glitchy loop. I spent an hour chasing down why my effect kept running after every render, and another hour figuring out why the cleanup function never seemed to fire. It felt like I was Neo dodging bullets in the Matrix—except I kept getting hit because I didn’t see the code’s hidden trajectory. The struggle was real, and I knew there had to be a better way to keep state and side‑effects in sync without the ceremony.

The Revelation (The Insight)

Then I discovered Hooks. The moment I saw useState and useEffect in action, it was like taking the red pill and seeing the underlying code structure for the first time. useState gives you a pair: a state variable and a setter function. Nothing more, nothing less—just like pulling a lever that updates a value and tells React to re‑render. useEffect is where side‑effects live: data fetching, subscriptions, manual DOM changes. You tell React when to run that effect by supplying a dependency array. If the array is empty, the effect runs once after the initial render (think componentDidMount). If you list props or state values, the effect re‑runs whenever any of those change (similar to componentDidUpdate). And if you return a function from the effect, React runs it as cleanup before the next execution or when the component unmounts—no more forgetting to unsubscribe or cancel timers. The biggest “aha!” was realizing that the setter from useState is stable; you never need to put it in the dependency array because React guarantees it won’t change. That little detail saved me from a hundred stale‑closure bugs.

Wielding the Power (Code & Examples)

The Struggle: Class Component Version

import React, { Component } from 'react';

class Timer extends Component {
  state = { seconds: 0 };

  componentDidMount() {
    this.interval = setInterval(() => {
      this.setState(prev => ({ seconds: prev.seconds + 1 }));
    }, 1000);
  }

  componentDidUpdate(prevProps, prevState) {
    // Imagine we wanted to log when seconds hit a multiple of 5
    if (this.state.seconds % 5 === 0 && prevState.seconds % 5 !== 0) {
      console.log('Five second tick!', this.state.seconds);
    }
  }

  componentWillUnmount() {
    clearInterval(this.interval);
  }

  render() {
    return <div>Seconds: {this.state.seconds}</div>;
  }
}

Look at all that lifecycle noise! If I forgot to clear the interval, I’d leak a timer. If I tried to read prevState inside the interval callback, I’d get a stale value unless I used the updater form. It’s easy to miss a cleanup step, and the logic is spread across three different methods.

The Victory: Hooks Version

import React, { useState, useEffect } from 'react';

function Timer() {
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      setSeconds(s => s + 1); // functional update → no stale closure
    }, 1000);

    // cleanup runs before the next effect or on unmount
    return () => clearInterval(id);
  }, []); // empty deps → run once, like componentDidMount

  // Optional: log every fifth tick without extra lifecycle methods
  useEffect(() => {
    if (seconds % 5 === 0) {
      console.log('Five second tick!', seconds);
    }
  }, [seconds]); // re‑run when seconds changes

  return <div>Seconds: {seconds}</div>;
}

See how the concerns are co‑located? The interval setup and its cleanup live right next to each other, and the dependency array makes it explicit when the effect should re‑run. No more guessing which lifecycle method to edit.

Traps to Avoid (The “Bosses” on Our Quest)

1. Missing Dependency Array – If you write useEffect(() => { … }) without the second argument, the effect runs after every render. That can turn a cheap interval into a runaway train.
   
   Fix: Always ask yourself, “What values does this effect depend on?” and list them.

2. Stale Closure with Setters – Imagine you do setSeconds(seconds + 1) inside the interval without the functional updater. The seconds captured is the value from the render where the effect ran, so the counter may freeze or jump unpredictably.
   
   Fix: Use the updater form setSeconds(s => s + 1) or include seconds in the dependency array (though the updater is usually cleaner).

3. Forgotten Cleanup – Subscriptions, timers, or event listeners left dangling cause memory leaks.
   
   Fix: Return a cleanup function from your effect; React will call it automatically.

Why This New Power Matters

Switching to Hooks didn’t just save me a few lines of code—it changed how I think about components. State and effects are now colocated, making it easier to see what a component does at a glance. Want to share logic? Extract a custom hook and reuse it everywhere, like a spell you can cast in any wizard tower. Testing becomes simpler because you’re dealing with plain functions, not tangled lifecycle methods. And the best part? The React team keeps refining the rules, so the mental model only gets stronger over time.

Quick Challenge

Try building a small “auto‑save” feature for a form: every time the user types, start a 2‑second timer; if they pause, save the data to localStorage. Use useState for the form values and useEffect with a dependency on the input value to reset the timer. See if you can avoid the stale‑closure trap and clean up the timer when the component unmounts.

What will you build next with your newfound Hooks power? Drop a link or a snippet in the comments—I can’t wait to see your creations!