React’s Render Props in Practice

Taking render props from theory into practice

Matti Bar-Zeev
Oct 28, 2018 · 8 min read
Photo by José Alejandro Cuffia on Unsplash

If you are a front-end developer using ReactJS, you’ve probably caught a lot of buzz about render props and how they are supposed to be this great solution for situations where your components become too complex to work with, but like me, never have realized how it comes to play in real life.

In the following story I will walk you through the phases of understanding how the need for render props arises, and when it does, how to make them work for you.


Such was the Pager component which we found ourselves discussing one fine afternoon in a meeting. A component containing Prev/Next arrow buttons which shifted the current page cursor and dispatched a “change” event to notify its surrounding components, but alas, now a new functionality and appearance requirements raised questions about the nature of this component.
The new version of the Pager component should include quick-paging buttons which allow you to jump to a certain page within a buffer of n pages, while still maintaining the old arrow buttons’ functionality.

Check out the images below:

The existing Pager component
The new enhanced Pager component

How would you approach it?

One of the suggestions was to add a variant to the component (a “prop” to the rest of the React world), which will determine the appearance and functionality we desire out of the existing component, while the other suggestion was to build a new component, since the implementation of the new requirements within the existing Pager component would make it a nightmare to maintain, and bug-prone due to high complexity.

The Gospel

A recent talk he gave in “React Rally 2018” was published and I took the 25 minutes to sit and watch it. This talk was called “Simply React”, and delivered content that could not be far from it.

Briefly put, he told the story of a poor React component developer who needed to keep extending her component’s functionality and appearance to a complete complexity and props mess, with the amazing twist at the end (spoiler alert!) — all the live demos for each enhancement presented were based on a single, 37 lines of code, component (the link to the presentation can be found at the bottom of this story). Wow!

Initial Thoughts

Getting to Work

Before we start, I’ll preface this by saying that the focus of the following code examples is on the core concepts brought in this story. You won’t see any fancy style references and some functionalities/validations will only be hinted in the code.

The Naive Start

(By the way, declaring the state as I did is made possible with this babel plugin)



In order to use it we will do the following:


Naive Pager

Now we’ve got a component which does what we want, but that’s about it and nothing more. The only way to alter its appearance without touching its core code is by changing the text which appears on the arrow buttons. We can’t even change the “pipe” separator if we want to. We need more.

The “Compound Components” Approach


This is where “Compound Components” comes in handy, basically declaring placeholders for the next/prev buttons which encapsulate the interaction logic of the Pager component. These are “inner” components inside our Pager component which we can later use when composing our final presentation.

Our compound components are named “Prev” and “Next” and both can get props of their own and render their children accordingly. Their children are what we would like to appear instead of just hard-coded text.

The way the compound component interacts with the “parent” component props is via the approved React Context API. This way we are able to provide nested DOM structure as our Next/Prev children which can still access the “parent” component’s state and props. In other words, the component’s context wraps its children’s rendering and gives them access to the cursor and pagesCount props plus the changePage method, all declared and managed in the “parent” component.

Notice that in this example I’m rendering “N/A” when the cursor reaches max or min, but that is just to emphasize that the Next and Prev compound components can act according to the cursor position. Let’s see how the component looks:



In order to use it we will do the following:


Compound component Pager

Now we have more control over the component’s appearance — we changed the Prev/Next into buttons and the separator from a pipe to a hyphen. We can even change the order and layout of these buttons using plain JSX and CSS while not risking the component’s functionality. Brilliant.

… but still not enough.

Render-Props FTW

A component with a render prop takes a function that returns a React element and calls it instead of implementing its own render logic.

(ReactJS docs)

In short, render props hand off the composition responsibility to the one using the component, which means that our basic Pager component should expose its API (state and callbacks) to be consumed by other composed components that are more focused on the desired appearance and functionality.

Our core functionality stays the same (pages, cursor, and event), but now there is a different appearance and interaction with the component which wraps the basic functionality. First, let’s see our basic Pager component and understand what’s going on there:



The interesting part in the basic component above is the render method. We see that we’re returning the invoke result of the component’s children, so we understand that the children of the PagerBasic should actually be a function, and this function receives 5 arguments — the cursor, the pagesCount, callbacks for prev/next, and changePage. You can see that the changePage implementation stays the same as within the previous component examples above.

Now that we have this basic component, how do we proceed? Let’s first attempt to implement our simple prev/next component using the PagerBasic component.



In the example above we’re declaring a functional component called PrevNextPager that uses the PagerBasic component and supplies the render function (i.e., the render props) to it as children.

Inside the render function we construct how we would like our component to look, relying on the arguments the function receives (remember the PagerBasic render method?). The state and logic of the component are kept intact within the PagerBasic component. In the PrevNextPager we simply supply the means to display and interact with it.

As you can see, using it is very simple. Give the component the props it requires and you have it! Now you can decide whether this should be a component declared in a separate file, or in the file using it, or even inline the JSX, it’s your call according to how you see the composed component usage in the future. Let it sink for a sec… pretty neat, right?

It’s time to deal with the more complex component. We start again by composing our basic component, but now we inject the page navigation part (the page navigation can even be a component on its own, but in order to keep things clearer I’ve implemented it inline). For this component we need to add an extra prop to support a buffer count which determines how many pages will be displayed between the arrows (we don’t have to, but why the hell not). We’ll add this prop to our new component.



This is the result:

Don’t be intimidated by the QuickPager render props implementation. It simply takes the buffer prop and creates those page buttons while assigning them the page index they represent. A click on each will call the changePage method (which is passed as an argument) with the desired page index. From there on, it’s all the PagerBasic’s job to take care of. I even marked the selected page with a corresponding className just to show that you can manage this selection outside the BasicPager. The BasicPager tells you which is the current selected page index. It’s your responsibility to do with the data as you wish.

It is also important to notice how we only added what’s needed where it is needed, i.e., the buffer prop. Other components relying on our BasicPager will not be affected by it. This, in turn, also helps keep our new component easy to maintain.


I’m happy to hear your thoughts on this story, so feel free to leave them here. You can also find me on Twitter @mattibarzeev.

Happy coding ☺


MyHeritage Engineering

MyHeritage helps you discover your family history and reveal the secrets from your DNA. Trusted by millions of families, we provide an easy way to share family stories, past and present, and treasure them for generations to come.

Matti Bar-Zeev

Written by

Mind reflections & individual thought patterns of one code musician ▪ Believes in craftsmanship ▪ Culture over Technology ▪ Always learning...

MyHeritage Engineering

MyHeritage helps you discover your family history and reveal the secrets from your DNA. Trusted by millions of families, we provide an easy way to share family stories, past and present, and treasure them for generations to come.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade