Lesson 24 of 80

Render Props

Q: What is the render props pattern, and how does a custom hook achieve the same goal more simply?

A strong answer covers: A render prop is a function prop that returns JSX, called by the owning component during its render, letting the owner supply logic/state and the caller supply display; Solves the same problem as custom hooks: reusing stateful logic across components without duplication; Custom hooks avoid the extra wrapper component and nested-JSX ('wrapper hell') cost render props introduce.

Sharing logic by passing a function as a prop that returns JSX — the pre-hooks answer to reusable stateful logic, still worth recognizing even though custom hooks replaced most of its use cases.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

In `<MouseTracker render={(pos) => <p>{pos.x}</p>} />`, which component owns the mouse-position state?

MouseTracker — it owns the state internally and passes it to the render functionThe caller — passing a render prop makes the caller responsible for the stateNeither — render props don't involve state at all

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Render Props

What interviewers actually ask about this, and what a strong answer has to cover.

What is the render props pattern, and how does a custom hook achieve the same goal more simply?

A strong answer covers

A render prop is a function prop that returns JSX, called by the owning component during its render, letting the owner supply logic/state and the caller supply display
Solves the same problem as custom hooks: reusing stateful logic across components without duplication
Custom hooks avoid the extra wrapper component and nested-JSX ('wrapper hell') cost render props introduce

Likely follow-ups

How would you rewrite the MouseTracker render-prop example as a custom hook?
What's 'wrapper hell,' and why do render props and HOCs both tend to cause it?
Would you introduce a new render-prop component in a modern hooks-based codebase? Why or why not?

Practice these with the AI interviewer →

The plain-language idea

A render prop is a prop whose value is a function that returns JSX — the component calls that function during its own render, handing it whatever data/state it manages internally:

function MouseTracker({ render }) {
  const [pos, setPos] = useState({ x: 0, y: 0 });
  return (
    <div onMouseMove={(e) => setPos({ x: e.clientX, y: e.clientY })}>
      {render(pos)}    {/* MouseTracker owns the state, caller decides what to render with it */}
    </div>
  );
}

<MouseTracker render={(pos) => <p>{pos.x}, {pos.y}</p>} />

MouseTracker owns the mouse-tracking logic (the state, the event listener); the caller supplies how to display it. This is exactly the same goal as a custom hook — reusable stateful logic, decoupled from any specific UI — solved with a different mechanism, before hooks existed.

Render props: handing back control, not just dataStep 1 of 3

<DataFetcher render={(data) => <List items={data} />} /> — a prop whose value is a function.

What people usually miss

Watch out

Render props predate hooks and mostly served the same goal — reusing stateful logic across components without duplicating it. Recognizing this is the connection interviewers are actually checking for.
They compose poorly compared to hooks. Nesting several render-prop components creates deep, hard-to-read JSX ("wrapper hell") — the same problem Higher-Order Components have, and one of the concrete reasons hooks were introduced.
You'll still encounter render props in older codebases and some libraries (React Router's older APIs, some animation libraries) — recognizing the pattern is more valuable today than reaching for it in new code.

Why this matters in interviews

"How did people share stateful logic between components before hooks existed?" checks whether your React knowledge goes back far enough to recognize render props and HOCs as real, still-encountered patterns — useful for reading legacy code even in an all-hooks codebase.