# React Hooks Masterclass: useState, useEffect, and Custom Hooks Explained
# React Hooks Masterclass: useState, useEffect, and Custom Hooks Explained
> **TL;DR:** React Hooks replaced class components by giving functional components the ability to manage state, run side effects, and share logic. This article builds a complete mental model — from how React remembers values between renders, to writing production-quality custom hooks — with runnable code every step of the way.
## Introduction
Before Hooks, writing a React component that fetched data on mount, subscribed to a browser event, and cleaned up after itself required a class component with `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount` — three separate places to express what is fundamentally one idea. Logic that belonged together was scattered. Logic that didn't belong together was crammed into the same lifecycle method.
Hooks changed that. Introduced in React 16.8, they let you use state and other React features from plain functions. But Hooks aren't just a syntax preference. They are a different way of *thinking* about components — one that centers on **what your component is doing** rather than when the framework calls it.
This article is for developers who know React basics but want to understand Hooks deeply enough to use them confidently in production. We'll build every concept from first principles, starting with the most fundamental question:
**How does React remember information between renders?**
---
## Background: How React Remembers Between Renders
A React functional component is just a function. Every time React needs to display an updated UI, it calls that function again. Variables declared inside the function are recreated from scratch on each call. So how does `useState` remember its value?
React maintains a **per-component, per-render fiber node** — an internal data structure that lives outside the component function itself. When you call `useState`, React reads from a slot in that fiber's memoized state array, keyed by the *order* in which hooks are called. This is why the Rules of Hooks exist: call hooks unconditionally, and always in the same order, so React can reliably match each hook call to its internal slot.
```mermaid
flowchart TD
A["Component Function Called"] --> B["Hook 1: useState — reads slot 0"]
B --> C["Hook 2: useState — reads slot 1"]
C --> D["Hook 3: useEffect — reads slot 2"]
D --> E["Returns JSX"]
E --> F["React reconciles & commits to DOM"]
F --> G{"State update triggered?"}
G -- Yes --> A
G -- No --> H["Idle — waiting"]
```
This slot-based model has a concrete implication: you cannot call hooks inside `if` statements or loops. If you did, the slot positions would shift between renders and React would read wrong values.
---
## Understanding useState
### What It Is
`useState` is a hook that lets a component *own* a piece of data that persists across renders and, when changed, triggers a re-render to display the updated UI.
The API is intentionally minimal:
```ts
const [value, setValue] = useState(initialValue);
```
`value` is the current state. `setValue` is a stable function that schedules an update. When you call `setValue`, React queues a re-render, the component function runs again, and the new `value` reflects your update.
### A Real Counter
Let's start with a counter, but build it in a way that shows the mechanics:
```tsx
import { useState } from 'react';
export function ArticleVoteCounter({ articleId }: { articleId: string }) {
const [upvotes, setUpvotes] = useState(0);
const [downvotes, setDownvotes] = useState(0);
const score = upvotes - downvotes;
return (
Article Score: {score}
);
}
```
A few things worth noting here:
1. **Two independent state variables**: `upvotes` and `downvotes` each occupy their own slot. They don't need to be grouped into one object unless their updates are always coordinated.
2. **Functional update form** (`prev => prev + 1`): When the new state depends on the old state, always use the functional form. This avoids stale closures in async scenarios.
3. **Derived values don't need their own state**: `score` is computed from existing state. Storing it separately would create a source of truth problem.
### State with Objects
When state is an object, remember that `setState` replaces the entire value — it doesn't merge like `this.setState` in class components:
```tsx
import { useState } from 'react';
interface UserProfile {
name: string;
bio: string;
avatarUrl: string;
}
export function ProfileEditor() {
const [profile, setProfile] = useState({
name: 'Ada Lovelace',
bio: 'Mathematician and writer.',
avatarUrl: '/avatars/ada.jpg',
});
function updateBio(newBio: string) {
// Spread existing fields — otherwise name and avatarUrl are lost
setProfile(prev => ({ ...prev, bio: newBio }));
}
return (