Solution

ToggleRenderProps owns the state and control semantics, then hands its child complete control over the rendered markup.

The problem, in plain English

Some behavior belongs together even when its visual presentations do not. A menu, disclosure, and mute button can all need the same boolean transitions, but forcing them through one hard-coded component also forces one DOM structure. A render prop separates those decisions: the component owns behavior, while a function supplied by the caller returns the elements.

The details matter. The initial prop is only a mount-time baseline, controls should not change identity on every render, and rapid toggles must compose instead of reading one stale value.

The mental model

Treat the component as a headless state machine. It produces an API object rather than markup; the child function consumes that object and produces the only DOM React receives.

A first attempt

The direct version appears to work for one click:

function ToggleRenderProps({ initialOn = false, children }) {
  const [on, setOn] = React.useState(Boolean(initialOn));

  return children({
    on,
    toggle: () => setOn(!on),
    setOn,
    reset: () => setOn(Boolean(initialOn)),
  });
}

Every render allocates new toggle and reset functions. More importantly, toggle closes over one rendered value, so multiple calls before React renders again all request the same next state. reset also follows the latest prop instead of the first mount baseline.

The working solution

const React = require('react');

function ToggleRenderProps({ initialOn = false, children }) {
  if (typeof children !== 'function') {
    throw new TypeError('ToggleRenderProps children must be a function.');
  }

  // useRef keeps the first mount's baseline even if the prop later changes.
  const initialRef = React.useRef(Boolean(initialOn));
  const [on, setOn] = React.useState(() => initialRef.current);

  // Functional state reads the latest queued value, so batched calls compose.
  const toggle = React.useCallback(() => {
    setOn((current) => !current);
  }, []);

  const reset = React.useCallback(() => {
    setOn(initialRef.current);
  }, []);

  return children({ on, toggle, setOn, reset });
}

module.exports = { ToggleRenderProps };

The ref captures the baseline once. React's state setter is already stable, while empty-dependency callbacks make toggle and reset stable too. The child is not memoized or stored: calling the current function during render guarantees a replacement child sees the live state immediately.

Why the controls stay correct

useState updater functions receive the pending state, not the value captured by one render. Three queued toggles therefore calculate false → true → false → true. useCallback keeps each command's identity stable because neither command needs a changing render value.

Walking through one call

Mount ToggleRenderProps with a truthy initialOn value and a button child. The initial coercion becomes true; the ref and state both receive that value. The child runs with on: true and returns a button labelled on.

Now call setOn(false). React stores false and renders again, calling the latest child with on: false. If the parent changes initialOn to false, nothing resets: the ref still holds the first true. Calling reset() reads that ref, restores true, and produces one more child render.

Gotchas

• Calling setOn(!on). Several toggles in one batch all read the same captured on. Use setOn(current => !current) so each update receives the previous queued result.
• Using the latest prop in reset. That silently changes the meaning of reset after a parent rerender. Capture Boolean(initialOn) in a ref on the first mount.
• Memoizing the API object. The object contains on, so it must change when the state changes. Stable command functions are the useful guarantee; a new four-field object is correct.
• Adding a wrapper. A headless render-props component should return the child's node directly. Even a convenience div changes layout and DOM semantics.
• Coercing every setOn value. The public setter follows React's boolean-state contract, including updater functions. Only the initial prop is coerced.

Going further

• Add an onChange(nextOn) notification by keeping the latest callback in a ref, while preserving stable control identities.
• Generalize the pattern into a reducer render prop that exposes state and dispatch for several related transitions.
• Compare render props with custom hooks: hooks usually remove nesting, while render props can enforce ownership and supply behavior to class components.