Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use a Render Prop

cdb.reacttraining.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Use a Render Prop

#11

Post by seanmcdirmid »

mcaruso wrote: post #7
tootie wrote: post #5

Even using the term "higher order" that seems like a very OOP solution, while render props is very functional and thus a better idiom for JavaScript.

"Higher order" sounds pretty functional to me. Higher order functions and all. Although I guess the term higher order function is hardly even spoken of in real functional languages because they're taken for granted.

The term “higher order” generally indicates complexity and indirection. If you can solve something first order, then that is much more preferable to a higher order (function, logic, object) solution. Higher order functions fall into the same category (you can have them if you want, but you must understand what you are getting into in terms of complexity).

Re: Use a Render Prop

#12

Post by couchand »

This technique is very useful, but passing the callback as a prop is an ugly way to do it. Much cleaner to pass the callback as children [0].

Then, the final example looks like:

  
    {({ x, y }) => (
      The mouse position is ({x}, {y})
    )}
[0]: https://discuss.reactjs.org/t/children-as-a-function-render-...

Re: Use a Render Prop

#13

Post by doomslice »

pspeter3 wrote: post #8

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.

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

Re: Use a Render Prop

#14

Post by bastawhiz »

pspeter3 wrote: post #8

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.

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.

Re: Use a Render Prop

#15

Post by pspeter3 »

doomslice wrote: post #13
pspeter3 wrote: post #8

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.

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

_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.

Re: Use a Render Prop

#16

Post by acemarke »

pspeter3 wrote: post #15
doomslice wrote: post #13

Earlier quoted context omitted.

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

_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'…

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... .

Re: Use a Render Prop

#17

Post by simplify »

seanmcdirmid wrote: post #11
mcaruso wrote: post #7

Earlier quoted context omitted.

"Higher order" sounds pretty functional to me. Higher order functions and all. Although I guess the term higher order function is hardly even spoken of in real functional languages because they're taken for granted.

The term “higher order” generally indicates complexity and indirection. If you can solve something first order, then that is much more preferable to a higher order (function, logic, object) solution. Higher order functions fall into the same category (you can have them if you want, but you must understand what you are getting into in terms of complexity).

> The term “higher order” generally indicates complexity and indirection.

As do all abstractions.

> If you can solve something first order, then that is much more preferable to a higher order solution.

a.k.a. "To abstract, or not to abstract?". It really depends, of course. But I know for certain I would not want to solve "mapping over an array" without the Array.prototype.map higher-order function.

Re: Use a Render Prop

#18

Post by andrewingram »

couchand wrote: post #12

This technique is very useful, but passing the callback as a prop is an ugly way to do it. Much cleaner to pass the callback as children [0]. Then, the final example looks like: {({ x, y }) => ( The mouse position is ({x}, {y}) )} [0]: https://discuss.reactjs.org/t/children-as-a-function-render-...

This is how the technique was first popularised by Cheng Lou in react-motion. But it was generally found that using children made it really inaccessible to people unfamiliar with the pattern.

I've literally had good developers not understand them until I switched an example from using children to using a render prop, at which point there's a big light bulb moment.

So i'll be sticking with the render prop.

Re: Use a Render Prop

#19

Post by wereHamster »

People seem to forget that components (stateless components, stateless functional components or whatever you want to call them) are just functions. One function calls another function, that's function composition. In plain JavaScript we do it all the time. But when React is involved people are suddenly all like: no you can't call that function directly, you have to name it 'Component' with a capital C and use like '' and to compose two Components you have to use a HOC. It's like they all forget how to JavaScript…

Re: Use a Render Prop

#20

Post by [deleted] »

wereHamster wrote: post #19

People seem to forget that components (stateless components, stateless functional components or whatever you want to call them) are just functions. One function calls another function, that's function composition. In plain JavaScript we do it all the time. But when React is involved people are suddenly all like: no you can't call that function directly, you have to name it 'Component' with a capital C and use like '…

[deleted]
Post reply on HN