[pspeter3]

As a note, it is not safe for a component using a render prop to implement shouldComponentUpdate. The problem is that the render prop may close over data that the component is unaware of. The Asana core components used to the use the render prop pattern until we discovered that issue and also realized it made tests harder to write. Now we use React.cloneElement instead.

[bastawhiz]

It also means you're passing in a new closure to the render prop on every render. You can move it to a member on your component's class, but that makes your code far hairier. It's also easy to forget to put it on the class, so you end up setting up eslint rules, and next thing you know, you've made everything worse.

[doomslice]

Would you mind elaborating on how React.cloneElement works vs this?

[pspeter3]

_On mobile so not a fully detailed response_

I came up with the pattern after discovering the issues with render callbacks and before Higher Order Components were common. You can achieve the same result with a Higher Order Component. The only benefit of this approach over an HOC is that you write a regular Component.

To implement the pattern, you make you Component expect a single child for it's `children` prop. Let's assume that the child has a `data` prop which is not set in the parent Component. In render, you return `React.cloneElement(this.props.children, { data: this.state.valueToInject })`.

The value of a Higher Order Component is that you can usually define a map to props function.

[acemarke]

Yep, I used this approach for a custom form change event buffering component that can wrap around input fields to allow fast updates while debouncing dispatching Redux actions: http://blog.isquaredsoftware.com/2017/01/practical-redux-par... .