Update 2: Added some language to clarify that “children as a function” is the same concept, just a different prop name.

Update 3: Render props are being used in React’s new context API, patterned after react-broadcast!

A few months ago, I tweeted:

MJ on Twitter

@reactjs I can do anything you're doing with your HOC using a regular component with a render prop. Come fight me.

I was suggesting that the higher-order component pattern that is a popular method of code reuse in many React codebases could be replaced 100% of the time with a regular component with a “render prop”. The “come fight me” part was a friendly taunt to the rest of the React community, and a good discussion ensued, but I was ultimately frustrated by my inability to fully express what I was trying to say in bursts of 140 chars apiece. I determined instead that I’d need to write something longer at some point in the future to really do it justice.

When Tyler invited me to speak at the Phoenix ReactJS meetup two weeks ago, I thought it’d be a great chance to explore the idea further. I was already going to be in Phoenix running our React Fundamentals and Advanced React workshops that week, and I’d heard great things about the meetup from my business partner Ryan who spoke there in April.

At the meetup, I gave a talk with the most click-bait-y title (sorry!) I could think of: Never Write Another HOC. You can watch the talk on Phoenix ReactJS’ YouTube channel, or in the embed below:

What follows is a brief summary of the talk in case you’d prefer to read it without watching the video. But seriously: watch the video. It’s more fun. 😀

If you skip the video and start reading, but you don’t quite grasp what I’m talking about, please go watch the video instead. There’s a lot more nuance in the spoken word!

The Problem with Mixins

I started the talk by discussing the main problem that higher-order components were designed to solve: code reuse.

Let’s back up a little bit to 2015–to the days of React.createClass. Let’s say you have a simple React app that tracks the mouse position and displays it on the page. The following is an example of how you might have built it:

Now, let’s imagine that we want to track the mouse position in another component as well. Can we reuse any of the code from our <App>?

In the createClass paradigm, the problem of code reuse was solved using a technique called “mixins”. Let’s create a MouseMixin that anyone can use to track the mouse position.

Problem solved, right?! Now anyone can simply “mix in” MouseMixin to their component class to get the x and y of the mouse in this.state!

HOCs Are the New Mixins

Then last year, ES6 classes arrived and ultimately the React team decided to move away from using createClass to use them instead. It was a wise decision. Who wants to maintain their own class model when JavaScript already has one built-in?

But there was a problem: ES6 classes don’t support mixins. Also, besides the fact they aren’t part of the ES6 class spec, mixins have other shortcomings too, many of which Dan discussed at length in a post on the React blog.

To summarize, problems with mixins are:

• ES6 classes. They don’t support mixins.
• Indirection. Mixins that modify state make it tricky to tell where that state is coming from, especially when there’s more than one mixin.
• Naming collisions. Two mixins that try to update the same piece of state may overwrite one another. The createClass API included a check that would warn you if two mixins had a getInitialState value with the same keys, but it wasn’t airtight.

So instead of using mixins, many in the React community eventually settled on an alternative technique for code reuse known as higher-order components, or HOCs. In this paradigm, code is shared using a similar technique to decorators; you start with the component that defines the bulk of the markup to be rendered and then wrap it in more components that contain the behavior you’d like to share. Instead of mixing in the behavior you need, you can just decorate your component! 😎

It was a good solution that solved the problem of code reuse elegantly in the brave new world of ES6 classes, and the community adopted it in droves.

At this point I’d like to stop and ask: what did we gain by moving to higher-order components? Did we solve any of the problems we had with mixins?

Let’s see:

• ES6 classes. Yep! No problems here. We can use HOCs with components created using ES6 classes.
• Indirection. We still have the same problem with indirection that we had when we were using mixins. Except this time instead of wondering where our state comes from we’re wondering which HOC provides which props.
• Naming collisions. Unfortunately we still have this problem too. Two HOCs that try to use the same prop name will collide and overwrite one another, except this time it’s slightly more insidious because React won’t warn us about the prop name collision. 😳

Another problem that both mixins and HOCs share is that they use static composition instead of dynamic composition. Ask yourself: where is the composition happening in the HOC paradigm? Static composition happens once, when the component class is created (e.g. AppWithMouse in the previous example).

You don’t use mixins or HOCs in your render method, which is a key piece of React’s dynamic composition model. When you compose in render, you get to take advantage of the full React lifecycle. This point is subtle, and probably deserves its own blog post at some point in the future, but I digress. 😅

So in summary: using a HOC with ES6 classes poses many of the same problems that mixins did with createClass, just re-arranged a bit.

Welcome to the new mixins! 🤗

In addition to these drawbacks, HOCs introduce a lot of ceremony due to the fact that they wrap components and create new ones instead of being mixed in to existing components. The component that is returned from the HOC needs to act as similarly as it can to the component that it wraps (it should take the same props, etc.) This fact alone requires a lot of boilerplate code just to build a robust HOC.

You can see a good example of what I’m talking about in the withRouter HOC that ships with React Router. The prop passing, the wrappedComponentRef, the hoisting of the wrapped component’s static properties, and other things are all part of the dance you need to do if you’re going to ship a HOC with your React library.

Render Props

There is another technique for sharing code that avoids the drawbacks of mixins and HOCs. At React Training, we call this technique “Render Props”.

The first time I ever saw a render prop was in Cheng Lou’s talk on react-motion at React Europe where he talked about the <Motion children> API that they were using to share interpolated animation values with the parent component. If I had to try and define it, I’d say something like this:

A render prop is a function prop that a component uses to know what to render.

More generally speaking, the idea is this: instead of “mixing in” or decorating a component to share behavior, just render a regular component with a function prop that it can use to share some state with you.

Continuing with the example above, we can simplify the withMouse HOC to a regular <Mouse> component with a render prop that is a function. Then, inside <Mouse>'s render, we can use that prop to know what to render!

The main concept to understand here is that the <Mouse> component essentially exposes its state to the <App> component by calling its render prop. Therefore, <App> can render whatever it wants with that state. Pretty cool. 😎

I should clarify at this point that “children as a function” is the exact same concept, just using the children prop instead of render. When I say “render prop” I’m not talking specifically about a prop named render, but rather the concept of having a prop that you use to render something. 😅

This technique avoids all of the problems we had with mixins and HOCs:

• ES6 classes. Yep, not a problem. We can use render props with components that are created using ES6 classes.
• Indirection. We don’t have to wonder where our state or props are coming from. We can see them in the render prop’s argument list.
• Naming collisions. There is no automatic merging of property names, so there is no chance for a naming collision.

And there’s absolutely no ceremony required to use a render prop because you’re not wrapping or decorating some other component. It’s just a function! Actually, if you’re using TypeScript or Flow, you’ll probably find it much easier to write a type definition for your component with a render prop than its equivalent HOC. Again, a topic for a separate post!

Additionally, the composition model here is dynamic! Everything happens inside of render, so we get to take full advantage of the React lifecycle and the natural flow of props & state.

Using this pattern, you can replace any HOC with a regular component with a render prop. And we can prove it, too! 😅

Render Props > HOCs

One of the most convincing pieces of evidence that render props are a more powerful pattern than HOCs is the fact that any HOC can be implemented using a render prop, but the inverse is not true. The following is an implementation of our withMouse HOC using a regular ol’ <Mouse>:

Observant readers may have already noticed that the withRouter HOC in the React Router codebase is actually implemented with … wait for it … a render prop!

So go ahead, try out render props in your codebase! Go and find some HOC and turn it into a regular component with a render prop. As you do, you should see a lot of the HOC ceremony code melt away and you’ll start to take better advantage of the dynamic composition model that React gives us, which is extremely cool. 😎

Michael is a partner at React Training and a prolific OSS contributor in the React community. To learn more about upcoming training workshops and courses, please subscribe to the mailing list and follow React Training on Twitter.

You know I hate you. How many times do I have to tell you? It’s getting old. Heck, it was old about a decade ago.

I’ve tried so hard to get rid of you! For years I thought I could just ignore you. That you’d go away on your own. That I’d grow out of you. That I could just exercise harder or eat better or pray longer and you’d get the hint and move on.

But alas, here we are again.

And you know, I think I’m starting to figure you out. After spending so much time with you over the past 20 years, I’m beginning to wonder if you’ll ever go away. So I’d better learn to deal with you. It’s either that or you’ll keep chipping away, trying to destroy me and everything I love.

The first thing I’ve learned about you is that you’re a phony. You are not an emotion. You, depression, are the lack of emotion. I used to mistake you for sadness, but I can see now that you’re different.

I can deal with sadness. Sadness is a natural feeling I get when my heart aches, usually when I miss someone. Without sadness, I’d have a hard time understanding what it truly means to be happy. But, depression, you don’t teach me anything about happiness. You are a numbness; a void. So I’m sorry to break it to you, but even sadness is better than you.

The second thing I’ve learned about you is that I did nothing wrong to deserve you. You aren’t the punishment for some misdeed. You’re a biological condition; a struggle of the mind.

I used to wonder what I needed to change in my life so that I’d make sure I never saw you again. What was I doing wrong? Maybe if I made more money or changed jobs or moved to a different place I could finally be free. Now I know that you are not the result of my circumstances. I view my struggle with you like any other workout. It’s going to take lots of time and dedication to put you in your place.

The third thing I’ve learned is that I have the power to choose my attitude. I always do, despite what you say. You and I have been face to face so many times, and lots of times you’ve convinced me that I can’t change; that I need to remain in my detached, numb, depressed state for a while longer and let it all just play out.

But you’re wrong. Even when you’re around I can choose to respond positively to the world around me. Even when I am depressed, it’s still my choice to do the things I do and say the things I say.

Because I choose to feel.

You see, I’ve got people who are counting on me, people who I love, and I refuse to just let them down.

When my son calls me late at night 20 years from now, I’m going to be there for him. He’ll probably call because, as a young father, he’s going to feel the weight of caring for his family. And that weight might tip the scales a little in his mind and open the door for you to sneak into his life too. And he’s going to need to talk to someone who can help him learn to feel again; to reject the numbness and start to learn some of the same things I’ve been learning about you and, more importantly, about himself. I’m sure as hell not going to just leave him to figure all this out on his own, the way I’ve had to.

So anyway, I just thought I’d set the record straight with you. Since you seem to like to stick around, you should at least know how I feel.

And I will always choose to feel.

Some years later, Ryan Dahl had this crazy idea to pair Google’s V8 JavaScript runtime with libev so developers would have a way to run their JavaScript outside the browser. And node.js became a thing. And npm. And the people rejoiced.

And people started writing web servers in JavaScript, and flying helicopters with JavaScript, and putting it on tablets and mobile phones, and embedding it in thermostats and refrigerators and pretty much anywhere they pleased. And there was a proliferation of JavaScript. And Serious Developers™ despised the common people who wrote JavaScript, but the people just kept writing more and more JavaScript.

And the people sought for a word to describe this widespread adoption of JavaScript, because the term “JavaScript” on its own was not sufficient to describe its vastness. So Charlie Robbins suggested that the term “Isomorphic JavaScript” might be used to describe JavaScript code that “can execute both on the client and the server”. And nobody knew what the hell it meant, but now instead of just writing JavaScript the people were writing Isomorphic JavaScript.

Wait … huh?

When coining the term Isomorphic JavaScript, Robbins explains that he meant “that any given line of code (with notable exceptions) can execute both on the client and the server”. However, if we examine more closely the meaning of the word isomorphic we read “corresponding or similar in form and relations”. In other words, two entities that are not the same but only look the same. This would be a great word to use when describing the relationship between jQuery and Zepto or Underscore and lodash, for example. These libraries are similar in form (they share the same API) but differ in underlying ideas and philosophy.

Instead, what we need is a word that describes the same code but running in a different environment. Nowadays we run JavaScript code not only on servers and in browsers, but on mobile and embedded devices as well. We’re running it on Raspberry Pis and Wii Us and iPhones. But this is a purely technical argument. What’s even more important is conveying understanding.

But of course, understanding is highly subjective. Recently, Ryan Florence and I began conducting React.js Training courses full-time. Up to this point we have trained several hundred developers, and it’s not uncommon for someone to ask what the word isomorphic means. Now, this is purely anecdotal evidence, but when we use the word universal instead of isomorphic everyone gets it. It may have something to do with Apple using that same word to describe application bundles that ran on both architectures back when they made the switch from PowerPC to Intel.

It’s true that there are two hard problems in computer science and one of them is naming things. Why? Because good names are important. A good name teaches about purpose and responsibility, so you have to spend some time thinking about it.

So let’s give our JavaScript code a name that people can understand; a name that indicates what it actually does instead of introducing words into the common vernacular that clearly don’t belong there; a name that teaches people that it runs not only on servers and browsers, but on native devices and embedded architectures as well.

Let’s call it Universal JavaScript.

My thanks to Ryan Florence, Pete Hunt, Peter Cooper, Dan Abramov, and Mark Dalgleish for reviewing this post prior to publication. Also, thanks to Ryan for riffing on these ideas with me.