After consulting multiple individuals in the Discord #reactiflux channel, I finally received the answer I sought.
There are essentially three use cases for React components, and in some scenarios, destructuring parameters can impact performance. It is crucial to have a clear understanding of what goes on behind the scenes.
Stateless functional component
const MyComponent = ({ name = 'John Doe', displayName = humanize(name), address = helper.getDefaultAddress() }) => {
return (
<div>{displayName}</div>
);
};
This represents a stateless, functional component. There is no state involved, and it is considered functional because it is not an instance of a Class, but rather a simple function.
In this case, there are no lifecycles such as componentWillMount, shouldComponentUpdate, or constructor. Since there is no lifecycle management, there is no impact on performance. This code is perfectly valid. Some may choose to handle the default value of displayName within the function body, but ultimately, it does not affect performance.
Stateless non-functional component
(Avoid doing this!)
class MyComponent extends React.Component {
render() {
const { name = 'John Doe', displayName = humanize(name), address = helper.getDefaultAddress() } = this.props;
return (
<div>{displayName}</div>
);
}
}
This falls under a stateless, non-functional component category. While there is no state involved, since it is a class, it is not truly "functional." Due to its nature as a class extending React.Component, it does possess a lifecycle. Methods like componentWillMount, shouldComponentUpdate, or constructor can be utilized.
The way this component is written is problematic primarily because React provides a defaultProps attribute for handling default prop values. It is recommended to utilize it with non-functional components since it will be called by all methods reliant on this.props.
The previous code snippet creates local variables named name and displayName, applying the default values only for the render method. In order to ensure default values apply universally (including React lifecycle methods), it is imperative to utilize the defaultProps instead.
Here is the revised approach to achieve the same outcome:
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 method guarantees that the name will always default to 'John Doe' if left undefined. Although the default value for address was addressed, displayName remains unresolved. Why?
Unfortunately, there isn't a workaround for this specific scenario yet. Since displayName depends on the name property, which cannot be accessed during defaultProps definition. The current solution is managing it directly within the render method. Perhaps a more effective method exists.
The issue doesn't arise with the address property, as it operates independently and does not rely on MyComponent properties.
Stateful non-functional component
This functions similarly to a "Stateless non-functional component." The presence of an internal state within the component does not change the behavior due to the existing lifecycle. Despite having additional internal states, the output remains consistent.
I trust this explanation aids comprehension when utilizing component destructuring. Personally, I favor the functional approach for its cleanliness (+1 for simplicity).
It may be preferable to consistently employ defaultProps across both functional and non-functional components (+1 for consistency).
Remember, being mindful of lifecycles with non-functional components necessitates the usage of defaultProps. Ultimately, the choice lies with you ;)
Edit 10-2019: defaultProps will eventually be phased out of the React API in the future. Refer to and https://github.com/reactjs/rfcs/pull/107 for further discussion on the RFC.