In this lesson, we'll take a step back and re-examine the problem of sharing Component logic by iterating our way to arrive at a new pattern called render props. A render prop is a function that renders JSX based on state and helper arguments. This pattern is the most flexible way to share component logic while giving complete UI flexibility. It's a remarkably simple and powerful pattern.
Had to watch a couple of times.... Really great, finally seeing how this can be used effectively. Thanks!
Sorry, I don't understand how this makes the rendering more flexible? Before we refactored to leverage render props, it seemed like we were still able to "control the rendering" of the child component because we are rendering the children:
<Toggle onToggle={onToggle}>
{({on, toggle}) => (
<div>
{on ? 'The button is on' : 'The button is off'}
<Switch on={on} onClick={toggle} />
<hr />
<button
aria-label="custom-button"
onClick={toggle}
>
{on ? 'on' : 'off'}
</button>
</div>
)}
</Toggle>
Can someone explain why this is more "flexible"?
<Toggle
onToggle={onToggle}>
renderUI={({on, toggle}) => (
<div>
{on ? 'The button is on' : 'The button is off'}
<Switch on={on} onClick={toggle} />
<hr />
<button aria-label="custom-button" onClick={toggle}>
{on ? 'on' : 'off'}
</button>
</div>
)}
/>
Sorry, I don't understand how this makes the rendering more flexible? Before we refactored to leverage render props, it seemed like we were still able to "control the rendering" of the child component because we are rendering the children:
<Toggle onToggle={onToggle}>
{({on, toggle}) => (
<div>
{on ? 'The button is on' : 'The button is off'}
<Switch on={on} onClick={toggle} />
<hr />
<button
aria-label="custom-button"
onClick={toggle}
>
{on ? 'on' : 'off'}
</button>
</div>
)}
</Toggle>
Can someone explain why this is more "flexible"?
<Toggle
onToggle={onToggle}>
renderUI={({on, toggle}) => (
<div>
{on ? 'The button is on' : 'The button is off'}
<Switch on={on} onClick={toggle} />
<hr />
<button aria-label="custom-button" onClick={toggle}>
{on ? 'on' : 'off'}
</button>
</div>
)}
/>
Sorry, I don't understand how this makes the rendering more flexible? Before we refactored to leverage render props, it seemed like we were still able to "control the rendering" of the child component because we are rendering the children:
<Toggle onToggle={onToggle}>
{({on, toggle}) => (
<div>
{on ? 'The button is on' : 'The button is off'}
<Switch on={on} onClick={toggle} />
<hr />
<button
aria-label="custom-button"
onClick={toggle}
>
{on ? 'on' : 'off'}
</button>
</div>
)}
</Toggle>
Can someone explain why this is more "flexible"?
<Toggle
onToggle={onToggle}>
renderUI={({on, toggle}) => (
<div>
{on ? 'The button is on' : 'The button is off'}
<Switch on={on} onClick={toggle} />
<hr />
<button aria-label="custom-button" onClick={toggle}>
{on ? 'on' : 'off'}
</button>
</div>
)}
/>
Phillip, I think that you're confused. If you look at the initial implementation the Toggle component doesn't call the children
function (or a renderUI
function) so what's rendered is determined by the Toggle component (it only renders a switch). Try watching the video again?
Hi Kent! Thanks for responding. You are correct. Thanks for clarifying!
Interestingly I ran into an error when I clicked on the toggle after using the CommonToggle. This was the result of not passing it the onToggle prop. Since Toggle components setState method assumes the onToggle prop, it fails. Solved by creating a deafultProp to the CommonToggle function or testing for an onToggle prop before calling it in the setState.
I really like these videos. I wish I didn't feel like a dum dum each time I watch these videos, but I appreciate it all the same. Thank you Kent!
Is there a reason the children function accepts an object instead of two arguments. Seems would be simpler. Thanks!