9

Stop returning NULL components

 2 years ago
source link: https://dev.to/ucvdesh/stop-returning-null-components-312k
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Cover image for Stop returning NULL components

Stop returning NULL components

May 26

・3 min read

Conditional rendering on React helps you build your apps avoiding unnecessary renders depending on some validations, and it can be used on tooltips, modals, drawer menus, etcetera. But, if we do it wrong, we can end up losing performance instead of improving our app.

It's pretty common to see something like this:

import React, {useState} from 'react';

export const MyComponent = ({}) => {
   const [show, setShow] = useState(false);
   return (
      <p>This is my main component</p>
      <MyChildComponent show={show} />
   )
} 

export const MyChildComponent = ({show}) => {
   return show ? <p>This is my child component</p> : null;
}
Enter fullscreen modeExit fullscreen mode

That is a mistake that can potentially increase a lot the performance of your application. Why? Because this is not conditional rendering, what we are doing in this example is returning a NULL component or, in other words, a component that renders NULL.

But you guys may think "Yeah, but...It's null, so it doesn't do anything". Au Contraire my friend, and the reason relies on its name NULL COMPONENT, and what does a component have? Right, a lifecycle. So, when we return a Null component we still have a full lifecycle that will trigger depending on what we do on their parent component.

  • The true Conditional Rendering:

To avoid these problems the correct way to do is to do the conditionals on the parent component to avoid even call that child component. We're gonna be using the same example:

import React, {useState} from 'react';

export const MyComponent = ({}) => {
   const [show, setShow] = useState(false);
   return (
      <p>This is my main component</p>
      show ?? <MyChildComponent />
   )
}

export const MyChildComponent = () => {
   return <p>This is my child component</p>;
}
Enter fullscreen modeExit fullscreen mode

Moving the show validation to the parent component instead of the child will make the rendering to be truly conditional. The only lifecycle that will trigger in this example will be only the MyComponent lifecycle because the MyChildComponent isn't even being called.

  • Why if we need the validation inside the component?

That can happen if we are working on legacy code and we need to fix something without changing every single one of the files where the component is being called. Then, we need to check if the validation will not change a lot in a short amount of time.

If that prop will not change a lot, we can use the memo() function provided by React to memoize that component and avoid unnecessary re-renders on that component and improve the performance of the app without a huge refactor. But, if this prop changes a lot, then we need to change the validation as we learn before, otherwise, the performance may drop.

If you're building something like a wrapper component that will have a conditional render inside of it but will always be rendered, for example, a Tooltip component wrapper another tip can be to manage the show as a state INSIDE the tooltip component and wrap it with the memo() function to avoid unnecessary re-renderings and prop passing to make the component reusable, autonomous and performant.


Do you have a different opinion? Do you think just like me? Do you like to add something to the post? Do it in the comments below!

I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK