`any` proptype should not be marked as required
See original GitHub issueIn the following example, foo
probably should not be marked as required:
type Props = {
foo: any,
}
const MyComp = (props: Props) => <div />
<MyComp foo={null} />
// Failed prop type: The prop `foo` is marked as required in `MyComp`, but its value is `null`.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
React - prop-types is marked as required - Stack Overflow
You're trying to load the <Rate /> component with a rate prop equal to this.state.rate in <App /> . Your App component state...
Read more >Don't Call PropTypes Warning - React
Don't call PropTypes directly Using PropTypes in any other way than annotating React components with them is no longer supported: var apiShape =...
Read more >How to validate React props using PropTypes - LogRocket Blog
Learn how to validate props with React PropTypes, React's internal mechanism for adding type checking to component props.
Read more >Warning for: PropTypes.object.isRequired when prop is `null ...
Requiring that a value or null must be specifically provided should absolutely be allowed via PropTypes. Here is the use case I'm running...
Read more >PropTypes.shape should support warn on missing required ...
My feature request was to have some warning when the object passed to a property can be statically analyzed, and is missing some...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@echenley did not run the updated code but looking at the test case coverage, this seems like it should work as I would expected
to result in
i.e. the behavior before the first PR
So :shipit:
For completeness of this thread, this is the new test echenley added. It handles both cases properly.