Render props

A render prop is a prop whose value is a function that returns JSX; the component calls it to render. Instead of returning fixed markup, the owning component invokes the function and passes its internal state and handlers as arguments. The caller receives them and decides what to draw. children is just a render prop with a special name — passing a function as children is the idiomatic form.

function Toggle({ children }: { children: (on: boolean, toggle: () => void) => React.ReactNode }) {
  const [on, setOn] = useState(false);
  const toggle = () => setOn((v) => !v);
  return <>{children(on, toggle)}</>; // hand state + handler back to the caller
}

// the caller owns the markup; Toggle owns the behavior
<Toggle>
  {(on, toggle) => (
    <button onClick={toggle} aria-pressed={on}>{on ? "On" : "Off"}</button>
  )}
</Toggle>

The component shares what it does without dictating what it looks like.

The data flow is an inversion: the child computes state, then calls up to the parent’s function to render it. Normal props flow parent → child. A render prop runs the other way at render time: Toggle is the one holding state, but it delegates the drawing back to whoever rendered it. This is inversion of control — the owning component controls behavior; the caller controls presentation. Two screens can share one Toggle and render wildly different UI.

// screen A — a switch
<Toggle>{(on, toggle) => <Switch checked={on} onChange={toggle} />}</Toggle>

// screen B — a labeled checkbox, same behavior, different markup
<Toggle>{(on, toggle) => (
  <label><input type="checkbox" checked={on} onChange={toggle} /> Notifications</label>
)}</Toggle>

Neither screen reimplements the toggle logic, and Toggle knows nothing about switches or checkboxes.

For pure logic reuse, a custom hook does the same job flatter — this is why render props faded. A render prop was historically the only way to share stateful logic without a class HOC. Hooks made the behavior callable directly, with no extra component and no nesting. If all you want is the on/off state, return it from a hook and let the consumer render normally.

function useToggle(initial = false) {
  const [on, setOn] = useState(initial);
  const toggle = useCallback(() => setOn((v) => !v), []);
  return [on, toggle] as const;
}

// no wrapper component, no function-child indentation — just values in scope
function NotificationRow() {
  const [on, toggle] = useToggle();
  return <Switch checked={on} onChange={toggle} />;
}

When the shared thing is logic that returns values, prefer the hook. It composes with other hooks, adds no tree depth, and reads top-to-bottom.

Render props are still the right tool when the component must inject something at render time. A hook returns values before you render; it cannot decide how each item draws inside a structure the library controls. When the owning component owns the rendering loop — a virtualized list deciding which rows are visible, a fetcher that renders one of loading/error/data branches, a measuring component that knows the box size — it must call back to you during its own render. That’s exactly a render prop.

// the library owns which rows exist this frame; YOU own each row's markup
<VirtualList items={users} rowHeight={48}>
  {(user, index) => <UserRow key={user.id} user={user} index={index} />}
</VirtualList>

// the fetcher owns the loading/error/data state machine; you render each branch
<Query url="/api/users">
  {(state) =>
    state.status === "loading" ? <Spinner />
    : state.status === "error" ? <Error msg={state.error} />
    : <List data={state.data} />}
</Query>

A hook can’t do this cleanly: it doesn’t sit inside the list’s render or the fetcher’s branch switch. Render-time injection is the render prop’s enduring niche.