As I was preparing this article, I was getting ready to give a training to engineers at a local company. They saw my Advanced React Component Patterns course on egghead.io and want to dive deeper into the Render Props pattern. (If you're unfamiliar with the Render Props pattern, I suggest you stop reading now and read "Use a Render Prop" or watch "Never Write Another HoC" (both by the illustrious Michael Jackson), then come back and continue).

In preparing for this training (in addition to creating this), I tweeted this question:

Kent C. Dodds 🌌 @kentcdodds

❓ I'm preparing some material about render props in React ⚛️ What are your questions about render props in React? What things are unclear about the pattern? Are there related patterns you'd like to know more about? What kinds of examples could help? 🔁 RT for reach please!

12:17 AM (UTC) · January 20th, 2018

32 210

I got quite a few great responses and for today's newsletter I thought I'd share three of them and simple examples for the answer:

Question 1: Performance?

This is by far the most common question I get whenever talking about Render Props (my tweet had several responses asking about performance). My answer to this question is simple: "That's a really common question. So I'm glad that Ryan Florence answered it in a great blog post! Read "React, Inline Functions, and Performance". "In summary" (to quote the article:

• Write your code naturally, code to the design.

• Measure your interactions to find slow paths. Here's how.

• Use PureComponent and shouldComponentUpdate only when you need to, skipping prop functions (unless they are used in lifecycle hooks for side-effects).

If you really believe that premature optimization is bad practice, then you won't need proof that inline functions are fast, you need proof that they are slow.

I should add one thing. If you're really concerned about inlining your render prop function and perf implications of that, then don't inline the function! :)

class MyComp extends React.Component {
	renderDownshift = (downshift) => <div>{/* Your UI stuff here */}</div>
	render() {
		return <Downshift>{this.renderDownshift}</Downshift>
	}
}

Question 2: Messy Render!?

The not-a-link-posting-robot Mark Erikson asked:

Mark Erikson @acemarke

@kentcdodds I'd like to see demonstrations of ways to use render props that DON'T involve stuffing the entire logic into nested functions right there in `render()`. In other words, can you still split out the render func logic into smaller functions for readability?

1:03 AM (UTC) · January 20th, 2018

1 13

Mark is correct. Almost every render prop example I've seen also just shows all the logic in the render function. It's normally an implicit return and then one giant expression. I used to be annoyed by giant render functions, but I've warmed up to them as I've realized that the only reason I didn't like them was because I thought they were complex... 🤔 🤓

In any case, because render props are literally just functions that get called with arguments, you can do whatever you like with them. So I made these two examples for Mark. Here's a smaller version of the concept:

function JustARegularFunctionComponent(props) {
	// do whatever you want in here
	return <div>{/* your stuff */}</div>
}

function App() {
	return (
		<div>
			<div>With a totally different component. Thanks React composibility!</div>
			<RenderPropComp
				render={(arg) => <JustARegularFunctionComponent {...arg} />}
			/>
			<hr />
			<div>
				Inline! You don't have to make it an implicit return arrow function 😉
			</div>
			<RenderPropComp
				render={(arg) => {
					// <-- notice the curly brace!
					// do whatever you want in here
					return <div>{/* your stuff */}</div>
				}}
			/>
		</div>
	)
}

Question 3: Lifecycle Hooks?

Another fairly common question is how to get access to the render prop arguments in lifecycle hooks (because your render prop function is called within the context of the render of your component, how do you get it into componentDidMount.

The answer to this is actually sort of hidden in the answer to Mark's question above. Notice that thanks to React's composability, we can create a separate component, and simply forward the arguments to the props of our component. Like this:

class RegularClassComponent extends React.Component {
	componentDidUpdate() {
		// here you are :)
		console.log(this.props.whatever)
	}
	render() {
		return <div>{/* your ui */}</div>
	}
}

function App() {
	return <RenderPropComp render={(arg) => <RegularClassComponent {...arg} />} />
}

My friend Donavon would be sad if I didn't bring up his preferred pattern of Component Injection. With component injection you could do this even more cleanly:

class RegularClassComponent extends React.Component {
	componentDidUpdate() {
		// here you are :)
		console.log(this.props.whatever)
	}
	render() {
		return <div>{/* your ui */}</div>
	}
}

function App() {
	return <CompInjectionComp component={RegularClassComponent} />
}

I'll leave the implementation details as an exercise for the reader... Or you could look at the new library Donavon created as a result of this conversation, which he published on an airplane ✈️ at 30,000 feet!

Conclusion

The render prop pattern is awesome. I'm looking forward to seeing more projects added to Jared Palmer's awesome-react-render-props! What I love about the Render Prop pattern is that it can encapsulate the logic of a component without sacrificing customizability and simplicity in the markup. More awesome to come I think... Good luck! 👍