This site runs best with JavaScript enabled.

Answers to common questions about render props

February 12, 2018


Because there's a ton of hype, and a bunch of questions ⚛️

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:

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! :)

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

Question 2: Messy Render!?

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

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:

1function JustARegularFunctionComponent(props) {
2 // do whatever you want in here
3 return <div>{/* your stuff */}</div>
4}
5
6function App() {
7 return (
8 <div>
9 <div>With a totally different component. Thanks React composibility!</div>
10 <RenderPropComp
11 render={arg => <JustARegularFunctionComponent {...arg} />}
12 />
13 <hr />
14 <div>
15 Inline! You don't have to make it an implicit return arrow function 😉
16 </div>
17 <RenderPropComp
18 render={arg => {
19 // <-- notice the curly brace!
20 // do whatever you want in here
21 return <div>{/* your stuff */}</div>
22 }}
23 />
24 </div>
25 )
26}

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. This was asked by @SavePointSam:

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:

1class RegularClassComponent extends React.Component {
2 componentDidUpdate() {
3 // here you are :)
4 console.log(this.props.whatever)
5 }
6 render() {
7 return <div>{/* your ui */}</div>
8 }
9}
10
11function App() {
12 return <RenderPropComp render={arg => <RegularClassComponent {...arg} />} />
13}

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:

1class RegularClassComponent extends React.Component {
2 componentDidUpdate() {
3 // here you are :)
4 console.log(this.props.whatever)
5 }
6 render() {
7 return <div>{/* your ui */}</div>
8 }
9}
10
11function App() {
12 return <CompInjectionComp component={RegularClassComponent} />
13}

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! 👍

Things to not miss:

Discuss on TwitterEdit post on GitHub

Share article
loading relevant upcoming workshops...
Kent C. Dodds

Kent C. Dodds is a JavaScript software engineer and teacher. He's taught hundreds of thousands of people how to make the world a better place with quality software development tools and practices. He lives with his wife and four kids in Utah.