Code-sharing in React using Render PropsNadeesha CabralBlockedUnblockFollowFollowingFeb 9Render Props is an increasingly popular method of sharing code between react components.
They are called Render Props (or render-props) because they allow “sharing code” via a render prop.
But for this exercise, we’ll do the same while sharing code with react’s own children prop for aesthetics.
Sharing code via functional childrenBecause of that, the title can be more aptly renamed as “Code-sharing in React using functional children props”.
The problemSince React embraces FP-style composition over inheritance, in the early days, the composition was mostly done using compose and statically.
And libraries like recompose made it really easy and straightforward.
If you wanted to write components that were stateless and pure functions, you would write something like:This was mostly better than sprinkling this.
setState everywhere as it made it easy for components to be “dumb and pure” and logic to be abstracted to seperate functions that could be tested independently.
But it had it’s own problems.
1.
Who put what in props?Since so many things are injected via “props”, it becomes harder to reason which composition injected what as the component becomes larger.
2.
Re-location of logicCo-located code is easier to read.
But since some of my logic is re-located to a place far away from it’s actual (and often times only) usage, it becomes harder to read things.
3.
Lack of type inferenceThis was my personal favorite gripe.
As a heavy user of Typescript, I ended up spending a lot of time trying to find a way to have robust types without writing a lot of my own types — but had little to no return from it.
A solutionInstead of providing re-usable logic via props, what if we can provide it via a children function?Let’s say I want the current date, updated every second to be shared across my React app.
I’d write a LiveDate component like this:Normally, children would be a JSX expression.
But here we assume children to be function.
And the caller of that function would get the { date: “…” } object.
Albeit, this is such a simple example.
But see if we share code this way, it solves all 3 of the above problems.
Re-usable logic is provided to the consumer as a React component, not polluting the props.
We know who provides liveDate as it’s very much co-located.
Type inference needs next to no effort because type systems can infer the type of liveDate based on the definition of LiveDate component.
In the wildA lot of the libraries that you might be using right now would support render-props out of the box.
Route component of the popular react-router lets you access properties like:react-powerplug is something that I use fairly heavily to do state management in my apps.
Declarative animation?.react-morph has got you covered.
But render-props do come with their own problems.
But for the 95% of use cases, they work very well over traditional composition methods.
React Hooks solves most of these problems.
In the meantime, for a list of other libraries that adopted the convention, check out this list.
.. More details