React - defaultProps vs ES6 default params when destructuring (performances issues)
I talked to several people on Discord #reactiflux channel and actually got the answer I was looking for.
There are basically three use-case with React components, and in some of them, destructuring params will impact performances so it is important to understand what's going on hunder the hood.
Stateless functional component
const MyComponent = ({ name = 'John Doe', displayName = humanize(name), address = helper.getDefaultAddress() }) => {
return (
<div>{displayName}</div>
);
};
This is a stateless, functional component. There is no state, and it is functional because it is not a Class
instance, but a simple function.
In this case, there is no life-cycle, you cannot have a componentWillMount
or shouldComponentUpdate
or constructor
there. And because there is no management of the life-cycle, there is no impact on performances whatsoever. This code is perfectly valid. Some may prefer to handle the default displayName
value within the function body, but in the end it doesn't really matter, it won't impact performances.
Stateless non-functional component
(Do not do this!)
class MyComponent extends React.Component {
render() {
const { name = 'John Doe', displayName = humanize(name), address = helper.getDefaultAddress() } = this.props;
return (
<div>{displayName}</div>
);
}
}
This is a stateless non-functional component. There is no state, but it is not "functional" since it is a class
. And because it is a class, extending React.Component
, it means you will have a life-cycle. You can have componentWillMount
or shouldComponentUpdate
or constructor
there.
And, because it has a life-cycle, the way of writing this component is bad. But why?
Simply put, React offers a defaultProps
attribute, to deal with default props values. And it is actually better to use it when dealing with non-functional components, because it will be called by all methods that rely on this.props
.
The previous code snippet creates new local variables named name
and displayName
, but the default values are applied for this render
method only!. If you want the default values to be applied for every method, such as the ones from the React life-cycle (shouldComponentUpdate
, etc.) then you must use the defaultProps
instead.
So, the previous code is actually a mistake that may lead to misunderstanding about the default value of name
.
Here is how it should be written instead, to get the same behavior:
class MyComponent extends React.Component {
render() {
const { name, displayName = humanize(name), address } = this.props;
return (
<div>{displayName}</div>
);
}
}
MyComponent.defaultProps = {
name: 'John Doe',
address: helper.getDefaultAddress(),
};
This is better. Because name will always be John Doe
if it wasn't defined. address
default value was also dealt with, but not displayName
... Why?
Well, I haven't found a way around that special use-case yet. Because the displayName
should be based on the name
property, which we cannot access (AFAIK) when defining defaultProps
. The only way I see is to deal with it in the render
method directly. Maybe there is a better way.
We don't have this issue with the address
property since it's not based on the MyComponent properties but rely on something totally independant which doesn't need the props.
Stateful non-functional component
It works exactly the same as "Stateless non-functional component". Because there is still a life-cycle the behavior will be the same. The fact that there is an additional internal state
in the component won't change anything.
I hope this helps to understand when using destructuring with components. I really like the functional way, it's much cleaner IMHO (+1 for simplicity).
You may prefer to always use defaultProps
, whether working with functional or non-functional components, it's also valid. (+1 for consistency)
Just be aware of the life-cycle with non-functional components which "requires" the use of defaultProps
. But in the end the choice is always yours ;)
Edit 10-2019: defaultProps will eventually be removed from React API at some point in the future, see https://stackoverflow.com/a/56443098/2391795 and https://github.com/reactjs/rfcs/pull/107 for the RFC.
One big difference between defaultProps
and default function parameters is that the former will be checked against propTypes. The require-default-props
rule of eslint-plugin-react explains it very well.
One advantage of
defaultProps
over custom default logic in your code is thatdefaultProps
are resolved by React before thePropTypes
typechecking happens, so typechecking will also apply to yourdefaultProps
. The same also holds true for stateless functional components: default function parameters do not behave the same asdefaultProps
and thus usingdefaultProps
is still preferred.