3 ms·
> The mechanism that enables code reusability is through composing components If you think that this: return ( <Apple> {({ apple }) => (
by thatswrong0 5y ago
> The mechanism that enables code reusability is through composing components
If you think that this:
return (
<Apple>
{({ apple }) => (
<Slicer slice={apple}>
{({ sliced: slicedApple } => (
<DinnerPlane contents={slicedApple} />
)
}
</Slicer>
)}
</Apple>
);
is more desirable than this:
const apple = useApple();
const slicedApple = useSlicer(apple);
return <DinnerPlate contents={slicedApple} />;
Then go for it I guess.
Although you'd have to somehow ignore the fact that you'd end up with an even bigger mess if you want these intermediate functionality steps to interact with the parent component in a non-trivial way, ..
Needless to say, I have written such render-prop and "renderless" components in the past, and I see very little upside compared to hooks.
- masterofmisc 5y agoThats interesting. So in your 2nd example, am I right in saying the variables 'apple' and 'slicedApple' are react JSX that you are ultimatly passing through to <DinnerPlate/> to render on the screen? If so, yes, that is fairly intuitive.
- thatswrong0 5y ago'apple' and 'slicedApple' would more likely be strings / objects / arrays in the real world. Maybe this still woefully contrived version is clearer? function FacebookComment({ commentId }) { const comment = useGetComment(commentId); const likes = useGetLikes(comment); return ( <div> <span>{comment.text}</span> <span>{likes.length} likes</span> </div> ); } I don't think deal with more braces right now to bring the alternative into existence unfortunately
- masterofmisc 5y agoOhh i see. Yes, that makes sense. Thanks for taking the time to reply.
- ctvo 5y ago??? <DinnerPlate>{...map <Slicer><Apple /><Slicer/> }</DinnerPlate>