Write a React custom hook `useToggle(initial = false)` that returns a boolean and a function that flips it. Why should the flip call `setOn(v => !v)` instead of `setOn(!on)`?

## The hook `useToggle` is the smallest useful custom hook and the one interviewers most often ask you to write on the spot, because it exercises three things at once: that a custom hook is just a function calling other hooks, that state updates are queued rather than applied immediately, and that a value read from a render is a snapshot. ```js import { useState, useCallback } from 'react'; function useToggle(initial = false) { const [on, setOn] = useState(initial); const toggle = useCallback(() => setOn(v => !v), []); return [on, toggle]; } ``` There is no magic in the `use` prefix beyond convention plus the lint rules that key off it. The hook has no special storage of its own: it calls `useState`, and React associates that state with the *component* that called the hook, in call order. ## Why the updater form, concretely Every render of a component produces a fresh set of local constants. Inside the render that produced `on === false`, the closure `() => setOn(!on)` is permanently a closure that computes `setOn(true)` — it does not re-read state later. That is fine in the ordinary case, because a click causes a render and the next click closes over the new value. It stops being fine in three real situations: 1. **Two flips in one event.** A handler that opens a menu and another that closes it both firing in the same click will both compute from the same snapshot. Since React 18, *all* updates batch — not only those inside event handlers — so both queued updates are applied before the next render, and `setOn(true); setOn(true)` collapses to one flip instead of two. 2. **A toggler captured by something long-lived.** If the toggler is handed to `setTimeout`, to `element.addEventListener` inside an effect that ran once, or stored in a ref, it keeps the value from the render where it was created forever. `!on` is frozen; `v => !v` is not. 3. **Callers who cannot see the current value.** A parent that only receives `toggle` has no way to pass the correct next state; the updater form makes that unnecessary. With the updater, React stores the function in the update queue for that state slot and calls it with the state as it stands after the preceding queued updates. Order is preserved, so N flips in one batch produce N flips. ```js // inside one click handler setOn(!on); // queued: -> true, then queued: -> true (net: on) setOn(!on); setOn(v => !v); // queued: false -> true, then true -> false (net: off) setOn(v => !v); ``` ## Stability of the returned function Because `v => !v` reads nothing from the enclosing render, the dependency array of `useCallback` is genuinely empty and the `toggle` identity stays the same for the component's whole lifetime. That matters when `toggle` is passed to a memoized child or used as an effect dependency: a toggler written as `() => setOn(!on)` would need `on` in its dependency list, would change identity on every flip, and would re-run anything that depends on it. The updater form is what makes the stable-identity version *correct*, not just shorter. (With the React Compiler enabled the memoization is inserted for you, but the correctness argument for the updater form is unchanged — the compiler does not fix a stale read.) ## Sensible variants Real codebases usually want more than a blind flip, because a menu or dialog often needs an explicit close: ```js function useToggle(initial = false) { const [on, setOn] = useState(initial); const toggle = useCallback(() => setOn(v => !v), []); const open = useCallback(() => setOn(true), []); const close = useCallback(() => setOn(false), []); return { on, toggle, open, close }; } ``` A lazy initial value is worth knowing about too: if computing the initial boolean is expensive, `useState(() => expensive())` runs the function only on the first render, whereas `useState(expensive())` calls it on every render and throws the result away. ## What it does not do `useToggle` does not give you a toggle that survives unmount, and it does not synchronise anything across components — each call site gets its own independent `useState` slot. If two distant components must see the same flag, the state has to live somewhere both can reach; the hook is a way to reuse the *logic*, and reusing it twice creates two independent booleans.