Today, I want to share a clean way to conditionally render child components while using React. It's very simple.
Live Demo:
https://codesandbox.io/s/if-component-demo-9iipl?file=/src/App.js
Before
function App(){
// ...
return <div>
{someCondition?
<SomeChildA>
<div>Some Contents</div>
<div>Some Contents</div>
<div>Some Contents</div>
</SomeChildA>
:
<SomeChildB>
<div>Some Contents</div>
<div>Some Contents</div>
<div>Some Contents</div>
</SomeChildB>}
</div>
}
After
function App(){
// ...
return <div>
<If condition={someCondition}>
<SomeChildA>
<div>Some Contents</div>
<div>Some Contents</div>
<div>Some Contents</div>
</SomeChildA>
</If>
<If condition={!someCondition}>
<SomeChildB>
<div>Some Contents</div>
<div>Some Contents</div>
<If condition={someOtherCondition}>
<NestExample/>
</If>
<div>Some Contents</div>
</SomeChildB>
</If>
</div>
}
<If/> Component
function If(props) {
return props.condition ? <>{props.children}</> : null;
}
Thanks for reading! Have a nice day!
Top comments (20)
IMO, the best way of doing that is this pattern
Much more concise, decently readable and short circuit saves some resources and possible runtime errors with not evaluating jsx.
Just out of curiosity: do you really think that evaluation of a control-flow-like one-liner might turn into a bottleneck in a react app?
I mean, I'm agree that this approach might be error prone if one works with deeply nested & all-levels fully optional objects/arrays (which isn't the most common use case in the world by the way) but do you think it may anyhow affect the rendering performance?
I mean, it seems unlikely that someone would just accidentially stitch in all DOOM engine logic re-written & adapted for JS in-between the
<If></If>
, isn't it?Thanks for the feedback!
I'm not sure if I understand you reply correctly, but here is demo that shows the child component will not be rendered unless the condition is true.
codesandbox.io/s/if-component-demo...
Output
If you change the code to this:
You will get a error.
Your idea is nice. However I think having an component would be overkill. Since the embed conditional rendering is already good.
I’d like to add a bit. Since you want to render the ComponentX only with some conditions, it’d be better if you could lazy load it. So it will be downloaded only when we need, therefore downsize the initial bundle. Lazy and Suspense can help you to do it.
Yes, it will cause an error. But it helps you write code in a more clean way. For example:
Since you will get an error by doing this way.
It forced you to do things like this which results a cleaner code:
Also, you can always check each property, but that is not recommended
If you mean the render of
<If/>
component will be executed regardless of the condition, that is true. But I don't think it will cause any error itself.For performance, so far I don't feel any drawback of using this approach since it does not render its children when condition if false as I mentioned previously.
It should be very similar to the
<Route/>
inReact-Router
.Best
I wanted to add the same comment about the content of the
<If>
being evaluated immediatelyand got some quite surprising results.
See here: codesandbox.io/s/if-component-b5zxk
Yes, a good example of how it works
I agree with @lukeshiru - This solution is really expensive. If you want to do this I would highly suggest you use a render prop.
Thanks for the feedback.
I don't think is good idea to put heavy task in the render return anyway so the performance does not suffer much by having a If wrappers.
If you have a case that may cause performance issue, please let me know
Forgive the total newb question but what is going on here? I have never seen naked HTML used like that in a Javascript function. What's going on there?
The function here is used in ReactJS environment.
It's a functional component in React.
This format is called JSX.
Best
Thanks for clarifying. I'd make sure to mention that in the article but perhaps the series is in that context and I just surfed in at a single chapter out of context. Not an unusual use case though so I'd aim to include a very brief intro in each chapter to make a newcomer aware of context I guess.
Thanks for point that out!
I will edit the post to add that.
Best
All good. Nice article. Alas I don't use React hence clueless on that syntax ;-). But a learning all the same. That's why dev.to is so nice.
thanks. this opened my eyes