Solution

You'll wrap a single boolean in useState and return it next to one small function that flips it — written so the flip is correct under batching and the function never changes identity.

The problem, in plain English

Half the controls in any interface are just on or off: a sidebar that's open or closed, a password field that's masked or shown, a dark-mode switch. Each one holds a boolean and needs a single action to invert it. useToggle packages that: it owns the boolean with useState and returns [value, toggle], where toggle() flips the value, toggle(true) or toggle(false) sets it outright, and toggle handed to an onClick still just flips even though React calls it with an event object.

The mental model

A custom hook is a function that calls other hooks. useToggle calls useState for the boolean, then returns that value alongside one function that changes it. The component reads value to decide what to render and calls toggle to change it. Two things have to be true about toggle: it must compute the next boolean from the latest value (not a frozen snapshot), and it must be the same function object on every render so it's a stable prop and dependency.

A first attempt

The obvious move is to read value and set it to its opposite:

const { useState } = require('react');

function useToggle(initialValue = false) {
  const [value, setValue] = useState(initialValue);

  const toggle = () => setValue(!value);

  return [value, toggle];
}

module.exports = { useToggle };

For a single click this works. Two problems hide underneath. First, value is a snapshot captured when the hook rendered — frozen at, say, false. If a handler calls toggle() twice in one event, both closures read that same frozen false and both call setValue(true); React batches them, and you end on true instead of back at false. Second, a brand-new toggle function is created on every render, so its identity churns — pass it to a memo-wrapped child and the memoization breaks. This version also can't honor toggle(true) / toggle(false): it ignores its argument entirely.

The working solution

const { useState, useCallback } = require('react');

function useToggle(initialValue = false) {
  const [value, setValue] = useState(initialValue);

  // useCallback with an empty dependency array returns the SAME function on
  // every render, so `toggle` keeps a stable identity. The functional updater
  // (v) => ... reads the value React is about to apply, so flips stack
  // correctly even when two land in one batch. We only treat `next` as an
  // explicit target when it is actually a boolean — a click event (an object)
  // falls through to the flip instead of being coerced to true.
  const toggle = useCallback((next) => {
    setValue((v) => (typeof next === 'boolean' ? next : !v));
  }, []);

  return [value, toggle];
}

module.exports = { useToggle };

Two shifts from the naive version. The updater is now a function ((v) => ...) instead of a value, so each call computes from the freshest pending state rather than a stale snapshot — two flips in one batch now cancel out. And toggle is wrapped in useCallback with an empty dependency array, so React hands back the identical function reference on every render. The typeof next === 'boolean' guard is what lets one function serve both jobs: a real boolean sets the value explicitly, while anything else — including the event object React passes to an onClick handler — falls through to a plain flip.

Walking through one call

Start with useToggle(false), so value is false. Now trace three uses of the returned toggle:

1. toggle() once. No argument, so next is undefined. setValue((v) => typeof undefined === 'boolean' ? undefined : !v) runs the updater with the pending value false, producing !false → true. The screen re-renders with true.
2. toggle() twice in one event. Both calls queue the same (v) => !v updater. React calls the first with the pending false → true, then the second with true → false. The batch resolves to false — right back where it started. The naive setValue(!value) would have seen false both times and landed on true.
3. toggle({ type: 'click' }) from an onClick. next is the event object. typeof next === 'boolean' is false, so the updater takes the !v branch and flips — the truthy object never gets mistaken for true. Had we written setValue(next), the value would have become the event object itself.

Because toggle came from useCallback([]), every one of these calls used the exact same function reference — the identity never changed across the re-renders.

Gotchas

• Reading stale state in the updater. setValue(!value) captures the value from the render that created the function, so two flips in one event both read the same snapshot and you flip only once. Fix: use the functional form setValue((v) => !v), which receives the freshest pending value.
• Coercing a non-boolean argument. Wiring toggle to onClick calls it with an event object; setValue(next) would store that object, and next ? true : false would always force true. Fix: guard with typeof next === 'boolean' so only a real boolean sets explicitly and everything else flips.
• Recreating toggle every render. Defining toggle as a plain arrow in the hook body makes a new function each render, defeating React.memo on children and tripping exhaustive-deps warnings. Fix: wrap it in useCallback with an empty dependency array — the functional updater needs no dependencies, so the function never has to change.
• Putting value in the dependency array. useCallback(..., [value]) rebuilds toggle on every change, throwing away the stable identity you wanted. Because the updater reads v from React rather than closing over value, the dependency array can stay empty.

Going further

• Named actions instead of a flip. A useToggle variant could also return { setTrue, setFalse } (each a useCallback) so callers can write onClick={setTrue} without remembering which boolean a bare toggle lands on.
• Cycling more than two states. Generalize to useCycle(['sm', 'md', 'lg']), where calling the returned function advances to the next item and wraps around — same functional-updater and stable-identity pattern, applied to an index instead of a boolean.
• Why the empty dependency array is safe here. It's tempting to fear a stale closure from useCallback([], ...), but the updater reads its input from React's pending state, not from a captured variable — so there's nothing stale to capture, and the function can safely live forever.