React Hooks ⚛️

1. Recap: useState gives a component memory

A plain function forgets everything between calls. useState fixes that: it stores a value across renders and gives you a setter to change it. Calling the setter tells React "this value changed — re-render me." The return value is always a pair: [value, setValue]. This box is read-only JSX; read every comment.

// useState gives a component MEMORY. Calling the setter re-renders the
// component with the new value. The pattern is always [value, setValue].

function Counter() {
  // useState(0) -> starts at 0. Returns the current value + a setter.
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
  // First render:  count = 0  -> "Clicked 0 times"
  // After 1 click: count = 1  -> "Clicked 1 times"  (React re-rendered)
}

2. useEffect — running side effects

A side effect is anything that reaches outside React to touch the wider world: fetching data, starting a timer, subscribing to an event, or writing to localStorage. useEffect runs that code after React paints the screen, so it never blocks rendering. The second argument — the dependency array — controls when it runs, and an optional returned function is the cleanup.

// useEffect runs code AFTER React paints the screen — for "side effects"
// like fetching data, timers, or subscriptions. The 2nd argument is the
// DEPENDENCY ARRAY: it tells React WHEN to re-run the effect.

function Timer({ userId }) {
  const [seconds, setSeconds] = useState(0);
  const [user, setUser] = useState(null);

  // 1) Run ONCE after the first render -> empty array []
  useEffect(() => {
    console.log("Component mounted");      // logs a single time
  }, []);                                  // [] = no dependencies

  // 2) Run when 'userId' CHANGES -> put it in the array
  useEffect(() => {
    fetch("/api/users/" + userId)
      .then(res => res.json())
      .then(setUser);                      // re-runs only if userId changes
  }, [userId]);

  // 3) Run AND clean up -> return a cleanup function
  useEffect(() => {
    const id = setInterval(() => {
      setSeconds(s => s + 1);              // tick every second
    }, 1000);
    return () => clearInterval(id);        // cleanup: stop the old timer
  }, []);                                  // before re-run / on unmount

  return <p>{seconds}s — {user?.name}</p>;
}

Run this to see how the dependency array decides whether an effect re-runs — it uses the exact same Object.is comparison React does internally.

// React's editor here runs plain JavaScript, so we SIMULATE how the
// dependency array decides whether an effect re-runs. The rule:
// React compares each item in the array to its value last render.
// If ANY item changed, the effect runs again.

function shouldEffectRun(prevDeps, nextDeps) {
  // Object.is is exactly the comparison React uses internally.
  if (prevDeps === null) return true;          // first render: always runs
  if (prevDeps.length !== nextDeps.length) return true;
  for (l
...

Your turn. The effect below should reconnect only when roomId changes, but the dependency array is empty. Fill in the blank so it watches the right variable, then run it and check the output.

// 🎯 YOUR TURN — this effect should re-run only when 'roomId' changes,
// but the dependency array is WRONG. Fix the blank, then run it.

function connectionLog(roomId, prevRoomId) {
  // We reuse the same comparison React uses for the deps array.
  function depsChanged(prev, next) {
    if (prev === null) return true;
    return !Object.is(prev[0], next[0]);
  }

  // 👉 The effect connects to a chat room. It must re-run when roomId
  //    changes. Replace ___ with the value that belongs in t
...

3. useRef — DOM refs and mutable values

useRef hands you a small box, { current: ... }, that survives re-renders but, unlike state, does not cause one when you change it. Two everyday jobs: grab a real DOM node (to focus an input or scroll an element) via the ref={...} attribute, and remember a value between renders without re-rendering (like a timer id).

// useRef holds a value in '.current' that SURVIVES re-renders but does
// NOT trigger one when you change it. Two main jobs:

// JOB 1 — Grab a real DOM node (so you can focus it, scroll it, etc.)
function SearchBox() {
  const inputRef = useRef(null);           // starts as null

  useEffect(() => {
    inputRef.current.focus();              // focus the <input> on mount
  }, []);

  return <input ref={inputRef} placeholder="Search..." />;
  // The ref={inputRef} wires the DOM node into inputRef.current.
}

// JOB 2 — Remember a value between renders WITHOUT re-rendering.
function Stopwatch() {
  const intervalRef = useRef(null);        // mutable "instance variable"

  function start() {
    intervalRef.current = setInterval(tick, 1000);  // store the timer id
  }
  function stop() {
    clearInterval(intervalRef.current);    // read it back later
  }
  // Changing intervalRef.current does NOT cause a re-render.
}

Run this to feel the key difference: a ref is just an object you can mutate in place, and mutating it never triggers a render — which is exactly why it's safe for a "count the renders" counter that state could never do without looping.

// Why useRef instead of useState sometimes? Because writing to a ref
// does NOT cause a re-render. We simulate a "render counter" — the
// classic ref use case.

// A ref is just an object: { current: <value> }. That's literally it.
const renderCountRef = { current: 0 };

function simulateRender(label) {
  renderCountRef.current = renderCountRef.current + 1;  // mutate in place
  console.log(label + " -> render #" + renderCountRef.current);
}

simulateRender("mount ");
simulateRender("update")
...

4. useContext — shared data without prop drilling

Passing a value down through many layers of components just to reach a deep child is called prop drilling, and it's tedious. useContext lets a deeply nested component read a value provided by an ancestor directly. It's perfect for things many components need: the current theme, the logged-in user, or the chosen language.

// useContext reads a value shared by an ancestor WITHOUT passing props
// down through every level ("prop drilling"). Three steps:

// 1) Create the context (often in its own file)
const ThemeContext = createContext("light");

// 2) Provide a value high up the tree
function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Toolbar />
    </ThemeContext.Provider>
  );
}

// 3) Read it anywhere below — no props needed
function ThemedButton() {
  const theme = useContext(ThemeContext);   // "dark"
  return <button className={theme}>Save</button>;
}

5. The Rules of Hooks

Hooks rely on being called in the same order on every render — that's how React keeps each one matched to its stored value. Break the order and React loses track. Two rules guarantee a stable order:

// ❌ WRONG — hook hidden behind a condition
if (isLoggedIn) {
  const [name, setName] = useState("");   // order changes between renders!
}

// ✅ RIGHT — hook at top level, condition inside
const [name, setName] = useState("");
if (isLoggedIn) { /* use name here */ }

6. Writing a custom hook

When two components need the same stateful logic, you don't copy-paste it — you extract it into a custom hook: a function named use... that calls other hooks and returns whatever you want. This is React's main way to reuse logic. Run the worked useCounter below; we fake useState with a closure so the logic runs in plain JS.

// A custom hook is just a FUNCTION whose name starts with 'use' and
// which calls other hooks. Here is a 'useCounter' written so it runs in
// plain JS — we fake useState with a tiny closure so you can SEE it work.

function fakeUseState(initial) {
  let value = initial;                       // the stored state
  const get = () => value;
  const set = (next) => {                     // accepts a value OR updater fn
    value = typeof next === "function" ? next(value) : next;
  };
  return [ge
...

// 🎯 MINI-CHALLENGE: write a custom hook called useToggle
//
// A 'useToggle' flips a boolean on and off — perfect for menus, modals,
// and dark mode. Build it using the fakeUseState helper provided.
//
// 1. Accept an 'initial' boolean (default false).
// 2. Keep the current value in fakeUseState.
// 3. Return an object: { isOn, toggle, setOn, setOff }
//      - toggle  -> flips true<->false   (use the updater form: v => !v)
//      - setOn   -> forces true
//      - setOff  -> forces false
/
...