Closed
Description
I made an example so it's easier to understand, but basically a warning is displayed in the console because of "missing required props".
The props are given to the element with React.cloneElement so I wasn't expecting to get a warning of missing props. I understand this could be an edge case though...
https://jsfiddle.net/kdsvgbzu/1/
<A name="name" value="value">
<B></B>
</A>
class A extends React.Component {
render() {
return (
<div>
{React.Children.map(this.props.children, function(child) {
return React.cloneElement(child, {
name: this.props.name,
value: this.props.value
});
}, this)}
</div>
);
}
}
A.propTypes = {
name: PropTypes.string.isRequired,
value: PropTypes.string.isRequired
};
class B extends React.Component {
render() {
return <span>{this.props.name} : {this.props.value}</span>;
}
}
B.propTypes = {
name: PropTypes.string.isRequired,
value: PropTypes.string.isRequired
};
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
[-]Props provided with cloneElement but a warning is still displayed[/-][+]Required props, provided with cloneElement still display a warning in the console[/+][-]Required props, provided with cloneElement still display a warning in the console[/-][+]Required props provided with cloneElement still display a warning in the console[/+]sophiebits commentedon Jul 27, 2015
This is intentional; validating props at element creation time produces more useful errors. It also more closely matches the behavior of static type systems like Flow. Best for now is to simply mark those props optional. We also may introduce a feature in the future called context that will give another supported way to pass props from a parent like A to a child like B.
tleunen commentedon Jul 27, 2015
That's what I thought. Thanks @spicyj
Add some defaultProps because of react/react#4494
fix(warnings): Warnings due to props not provided before React.cloneE…
micaste commentedon Mar 1, 2017
I don't know what was your real use-case @tleunen, but I stumbled upon this issue while implementing a reusable component that had the responsiblity to pass props to its children:
In the end, I worked around the issue with what I found is a more elegant solution:
I like it much better since the dependency of
ComponentRequiringTheNumberis explicit, and the role ofNumberSelectorbecomes apparent. And this way, the props given to the nested component are only evaluated when it is relevant.Applied to your Fiddle : https://jsfiddle.net/ap1e9rk3/1/
Remove onClose as required