Skip to content
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

Fix for #5468: Validate proptype definitions sooner #6316

Merged
merged 6 commits into from
Jun 29, 2016

Conversation

troydemonbreun
Copy link
Contributor

Fix for #5468

Added typeCheckWarn() func and updated the oneOf/oneOfType tests
Added warning for invalid oneOf/OneOfType args

This is my first contribution to React, any feedback is appreciated. :)

@jimfb
Copy link
Contributor

jimfb commented Mar 24, 2016

@zpao do you want to provide feedback? This PR has been idle for three days, and we should provide a response.

@troydemonbreun
Copy link
Contributor Author

Thanks @jimfb !

@gaearon
Copy link
Collaborator

gaearon commented Mar 27, 2016

Please note that in the future, if you see that another PR that fixes this issue already exists, it’s best to ask the original submitter whether they intend to finish their work before starting a new PR. In this case, the implementation in #5476 was waiting for review after a discussion, but we didn’t review it timely. I closed the old PR because this one is more up to date but I didn’t feel very good about this, and at least pinging the author a couple of times would be a good idea in retrospect. No hard feelings though, and thank you for contributing 😉 . Usually PRs are linked from the issues, and I can see a link from #5468 to #5476. It’s a good idea to look through such links before jumping into implementation. Cheers!

@troydemonbreun
Copy link
Contributor Author

@gaearon Oh, man, I'm sorry. I thought that PR has been rejected, and I'm new to OS contribution. In the issue thread I told @rppc to take my code (it's basically similar, not too many different ways to do it) and make his own PR. @zpao @jimfb - @rppc deserves the credit.

@gaearon
Copy link
Collaborator

gaearon commented Mar 27, 2016

Don’t worry about it! 😄
I shouldn’t have been so harsh in the previous message.

This happens a lot, and I personally did this mistake more than once. Some people take it harder so it’s usually best to try to avoid this but @rppc doesn’t mind so we’re all good here.

Cheers!

@troydemonbreun
Copy link
Contributor Author

@gaearon Great, thanks!

@gaearon
Copy link
Collaborator

gaearon commented Mar 28, 2016

@zpao What do you think? If all is good it’s best we merge this before it becomes outdated like #5476 😄

@gaearon gaearon added this to the 15.x milestone Mar 28, 2016
@zpao zpao modified the milestones: 15.y.0, 15-next Jun 1, 2016
@zpao zpao modified the milestone: 15-next Jun 14, 2016
@gaearon
Copy link
Collaborator

gaearon commented Jun 26, 2016

I think we should silence the proptypes warning, and make the initial warning the only one.
It’s confusing that it is displayed twice, and it doesn’t really help:

screen shot 2016-06-26 at 21 15 55

@@ -45,6 +45,13 @@ function typeCheckPass(declaration, value) {
expect(error).toBe(null);
}

function typeCheckWarn(propTypeFunc, message) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This helper is a little bit confusing because it pretends to be similar to typeCheckPass and typeCheckFail but has a completely different purpose and signature. Let’s just write this code explicitly inline in the corresponding test cases. Additionally, we can remove typeCheckFail calls from them because I think we only want the warning to appear once.

Added typeCheckWarn() func and updated the oneOf/oneOfType tests
Added __DEV__ warning for invalid oneOf/OneOfType args
@troydemonbreun
Copy link
Contributor Author

@gaearon how's this look?

(btw, I was listening to a podcast this week that interviewed you (shortly before you came to Facebook) that was discussing your next thing, and I think I may have heard a knowing tone in your voice when you said you weren't sure yet. ;-) )

);
});
if (__DEV__) {
warning(false, 'Invalid argument supplied to oneOf, expected an instance of array.');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would still want to return a function for consistency—it would just be a no-op.

Copy link
Contributor Author

@troydemonbreun troydemonbreun Jun 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gaearon no-oped, or should I return false?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let’s use emptyFunction.thatReturnsNull (if I recall correctly)

@@ -229,6 +229,7 @@ function createEnumTypeChecker(expectedValues) {
if (!Array.isArray(expectedValues)) {
if (__DEV__) {
warning(false, 'Invalid argument supplied to oneOf, expected an instance of array.');
return function() {};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use emptyFunction module for consistency.

warning(false, 'Invalid argument supplied to oneOf, expected an instance of array.');
return emptyFunction.thatReturnsNull;
} else {
return createChainableTypeChecker(function() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency with DEV behavior, let’s return emptyFunction.thatReturnsNull here as well. This way we treat bad argument as early DEV warning, and since we can’t really check propTypes, we don’t.

Not that all these semantics really matter because nobody should be calling prop types in prod but it’s best to have them behave the same way until we explicitly disallow it.

Copy link
Contributor Author

@troydemonbreun troydemonbreun Jun 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gaearon oh, so don't call createChainableTypeChecker as an alternate branch flow, always call warning?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gaearon pushed my interpretation of your comments, thanks

'red',
'Invalid argument supplied to oneOf, expected an instance of array.'
);
spyOn(console, ['error']);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you change this to spyOn(console, 'error') like the rest of the codebase does?

@gaearon gaearon added this to the 15-next milestone Jun 29, 2016
@gaearon gaearon merged commit 6cc037b into facebook:master Jun 29, 2016
@gaearon
Copy link
Collaborator

gaearon commented Jun 29, 2016

Thank you!

@troydemonbreun
Copy link
Contributor Author

Great, thanks!

@troydemonbreun troydemonbreun deleted the r-5468 branch June 29, 2016 17:11
@zpao zpao modified the milestones: 15-next, 15.3.0 Jul 13, 2016
zpao pushed a commit that referenced this pull request Jul 13, 2016
* Fix for 5468: Validate proptype definitions sooner

Added typeCheckWarn() func and updated the oneOf/oneOfType tests
Added __DEV__ warning for invalid oneOf/OneOfType args

* Suppress redundant error on warn; typeCheckWarn() removed

* Return no-op

* Using emptyFunction module for consistency

* Remove createChainableTypeChecker() call

* Adjust test to assert type check passes when warned

(cherry picked from commit 6cc037b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants