checkPropTypes: add argument that allows external logging #54
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks! If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions. |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
|
@gaearon Is this a good approach to using prop-types checking outside of React? Or is there a better way? |
|
Sorry, we're busy with many other things right now, and it's unlikely we'll have time to review PRs to
|
When specified, the argument `warningLogger` will be called with the same arguments as `warning`. Instead of logging errors to the fbjs warning logger, we are able to handle them externally. Fixes facebook#34
|
The PR has been updated to not throw an error, but instead calls the function passed in as an argument, with the same arguments as are passed to |
rufman
changed the title
|
I'm aware that there might not be time to review this PR, but with React 16 in beta now the resolution on how to use prop-types with custom errors is becoming a more prominent issue. I was wondering if there is anything else that would need to be done on this PR to have it merged. Or if such a feature won't be considered for the prop-types package, we'll look into alternatives. |
|
Any traction here? This is something we're interested in as well. |
|
@kaiyoma I used |
PropTypes.checkPropTypes cannot throw yet (see [1]), so checking console.error output [1] facebook/prop-types#54
PropTypes.checkPropTypes cannot throw yet (see [1]), so checking console.error output [1] facebook/prop-types#54
PropTypes.checkPropTypes cannot throw yet (see [1]), so checking console.error output [1] facebook/prop-types#54
PropTypes.checkPropTypes cannot throw yet (see [1]), so checking console.error output [1] facebook/prop-types#54
PropTypes.checkPropTypes cannot throw yet (see [1]), so checking console.error output [1] facebook/prop-types#54
PropTypes.checkPropTypes cannot throw yet (see [1]), so checking console.error output [1] facebook/prop-types#54
PropTypes.checkPropTypes cannot throw yet (see [1]), so checking console.error output [1] facebook/prop-types#54
PropTypes.checkPropTypes cannot throw yet (see [1]), so checking console.error output [1] facebook/prop-types#54
|
This would also be super useful to me. Any word on whether this might make it in? If it won't, then closing this PR and "officially" referring users to another project that does this might be a good move. |
There was a problem hiding this comment.
This looks good, but I'm going to hold off merging it for a bit; while adding an argument is generally semver-minor, if anyone was passing a non-function here, this would suddenly throw (and i think throwing when they pass a truthy non-function is the right behavior)
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
This has been here for quite a while, and have read little to no objections to merging this PR aside from "time" constraints. This would be a wonderful addition to the propTypes library and I am genuinely confused as to what it would take to consider merging it. |
When using prop-types for checking things outside of React, having
checkPropTypesthrow an error instead of swallowing it and logging it toconsole.errorcan be useful. The flagthrowErrorswill throw the error if set to true instead of logging it. AcheckPropTypeWithErrorsconvenience function, which callscheckPropTypeswiththrowErrorsset totruehas also been added.Fixes #34