-
Notifications
You must be signed in to change notification settings - Fork 47.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't isomorphically check propTypes in react-dom-stream SSR without warnings in React 15.2+ #7765
Comments
The warning is a false positive, you can safely ignore it. It occurs because There are a few solutions but they’re not on our side:
I hope this helps! |
Okay, I was actually concerned that I'm confused what you mean about cherry-picking #7219 though? I was expecting some kind of code change, not a documentation change. Thanks! |
Oops sorry. I meant #7132. |
The warning exists to make it clear for people who call PropTypes manually (e.g. to validate their API responses, or for other obscure reasons) that this won’t work in production in 16. We warn in development because that’s where people will see the warnings, as almost nobody looks into production warning logs. But PropTypes will keep working in development for sure, even in 16. |
aickin/react-dom-stream#22
react-dom-stream
helpfully checkspropTypes
while rendering static HTML to a stream. But of course React 15.2+ warns (in this case on a userHtml
Component
withpropTypes.head
):The page at that link advises 3rd party libraries to use external
PropType
libraries, but that won't work in this case becausereact-dom-stream
is trying to call thepropTypes
the user has put on their components, rather than providing helpers like the 3rd party libraries the author of that page seems to be considering (e.g.ImmutablePropTypes
). To prevent these errors, the user would have to remove thepropTypes
on their components or replace the usages ofReact.PropTypes
in their own code with some other library. If they were using 3rd party components that declarepropTypes
, they would be out of luck.Is there an intended solution to this or was this conflict unanticipated?
The text was updated successfully, but these errors were encountered: