Fixed invalid prop types error message to be more specific #11308

NicBonetto · 2017-10-20T22:28:54Z

Before submitting a pull request, please make sure the following is done:

Fork the repository and create your branch from master.
Run yarn in the repository root.
If you've fixed a bug or added code that should be tested, add tests!
Ensure the test suite passes (yarn test). Tip: yarn test --watch TestName is helpful in development.
Format your code with prettier (yarn prettier).
Make sure your code lints (yarn lint). Tip: yarn linc to only check changed files.
Run the Flow typechecks (yarn flow).
If you haven't already, complete the CLA.

Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html

NicBonetto · 2017-10-20T22:29:32Z

sebmarkbage · 2017-10-21T02:58:59Z

packages/react-dom/src/shared/ReactDOMUnknownPropertyHook.js

-          'the value to a string.%s',
+        'If you intentionally tried to pass a boolean, pass it as a string ' +
+          'instead: `%s`="`%s`". If you mean to conditionally pass an ' +
+          'attribute, use a ternary expression: `%s`={condition ? value : null}.%s',


If the value is true then this is very unlikely to happen because the problematic pattern is condition && value specifically. I can't think of a way where you'd end up with true for the same reason. Maybe we should have two separate error messages for true and false where this recommendation is only for the false case?

Maybe also call out that the problematic pattern is condition && value specifically, so that people know what's wrong and what to look for along with your proposed recommendation.

Also, the recommendation should be to pass undefined, not null. It doesn't really matter for DOM components, but if it is a custom component that is the difference between defaultProps working and not working. So it's better to have consistent advice.

NicBonetto · 2017-10-25T00:15:35Z

I may need some help with the error that occurred in the integration test. I believe it is coming from adding an additional condition in the if statement, and I would appreciate a little direction. Thank you.

gaearon

The overall structure is a bit hard to understand.

It's currently:

if (a && b) {
  warning(c, ...)
  return true
} else if (a) {
  warning(c, ...)
  //  warnedProps[...] = true <-- missing for some reason
  // return true <-- missing for some reason
}

Can you think of ways to simplify it?

For example:

if (a && !c) {
  if (b) {
    warning(false, ...)
  } else {
    warning(false, ...)
  }
  warnedProps[...] = true
  return true
}

gaearon · 2017-10-26T16:55:45Z

packages/react-dom/src/shared/ReactDOMUnknownPropertyHook.js

@@ -189,8 +200,6 @@ if (__DEV__) {
        name,
        getStackAddendum(),
      );
-      warnedProperties[name] = true;
-      return true;


Why was this removed?

gaearon · 2017-10-26T20:23:25Z

packages/react-dom/src/shared/ReactDOMUnknownPropertyHook.js

+    if (typeof value === 'boolean') {
+      if (value === true) {
+        warning(
+          DOMProperty.shouldAttributeAcceptBooleanValue(name),


Can we make this warning(false and move out this (negated) condition together with the top one?

Yes :) Just so I have a correct understanding, the refactor will look like:

if (typeof value === 'boolean' && !false) { if (value === true) { warning(false, ... ); } else { warning(false, ... ); } ... }

Is this the branching logic you prefer? I do not understand the !false condition, so if I am incorrect please explain what should take it's place.

if (typeof value === 'boolean' && !DOMProperty.shouldAttributeAcceptBooleanValue(name)) { if (value === true) { warning(false, ... ); } else { warning(false, ... ); } ... }

gaearon · 2017-10-26T23:41:04Z

packages/react-dom/src/__tests__/ReactDOMAttribute-test.js

@@ -54,8 +54,8 @@ describe('ReactDOM unknown attribute', () => {
      expectDev(
        normalizeCodeLocInfo(console.error.calls.argsFor(0)[0]),
      ).toMatch(
-        'Warning: Received `true` for non-boolean attribute `unknown`. ' +
-          'If this is expected, cast the value to a string.\n' +
+        'Warning: Received `true` for non-boolean attribute `unknown`. If this is expected, cast ' +


This change is unnecessary, right? It just reformats the message in a slightly less readable way.

gaearon · 2017-10-26T23:41:38Z

packages/react-dom/src/__tests__/ReactDOMComponent-test.js

@@ -2042,7 +2042,8 @@ describe('ReactDOMComponent', () => {
      expect(el.hasAttribute('whatever')).toBe(false);

      expectDev(console.error.calls.argsFor(0)[0]).toContain(
-        'Warning: Received `true` for non-boolean attribute `whatever`',
+        'Received `true` for non-boolean attribute `whatever`. If this is expected, cast ' +


Would look nicer if If this is expected... started on the new line in test.

gaearon · 2017-10-26T23:41:43Z

packages/react-dom/src/__tests__/ReactDOMComponent-test.js

@@ -2055,7 +2056,8 @@ describe('ReactDOMComponent', () => {
      expect(el.hasAttribute('whatever')).toBe(false);

      expectDev(console.error.calls.argsFor(0)[0]).toContain(
-        'Warning: Received `true` for non-boolean attribute `whatever`',
+        'Received `true` for non-boolean attribute `whatever`. If this is expected, cast ' +


gaearon · 2017-10-26T23:41:49Z

packages/react-dom/src/__tests__/ReactDOMComponent-test.js

@@ -2230,7 +2232,8 @@ describe('ReactDOMComponent', () => {
      expect(el.hasAttribute('whatever')).toBe(false);

      expectDev(console.error.calls.argsFor(0)[0]).toContain(
-        'Warning: Received `true` for non-boolean attribute `whatever`.',
+        'Received `true` for non-boolean attribute `whatever`. If this is expected, cast ' +


gaearon · 2017-10-26T23:43:19Z

packages/react-dom/src/__tests__/ReactDOMComponent-test.js

-        'Warning: Received `false` for non-boolean attribute `whatever`.',
+        'If you mean to conditionally pass an attribute, use a ternary ' +
+          'expression: `false`={condition ? value : undefined} instead of ' +
+          '{condition && value}.',


What does false={condition? value : undefined} mean? Why does it says false?

Please fix this to show the attribute name.

gaearon · 2017-10-26T23:44:49Z

packages/react-dom/src/shared/ReactDOMUnknownPropertyHook.js

+      } else {
+        warning(
+          false,
+          'If you mean to conditionally pass an attribute, use a ternary ' +


Can this also start with Received ... for non-boolean attribute ...? I want both messages to look similar, but with different second sentences.

gaearon · 2017-10-28T17:51:03Z

I tried to build React locally and then used

ReactDOM.render(
   <h1 myattribute={false}>Hello World!</h1>,
    document.getElementById('container')
);

I saw this message:

Does it make sense to you? I don't think its says what it's supposed to say.

gaearon · 2017-10-28T17:52:40Z

packages/react-dom/src/__tests__/ReactDOMComponent-test.js

@@ -2283,7 +2286,9 @@ describe('ReactDOMComponent', () => {

      expectDev(console.error.calls.count()).toBe(1);
      expectDev(console.error.calls.argsFor(0)[0]).toContain(
-        'Warning: Received `false` for non-boolean attribute `whatever`.',
+        'Received `false` for non-boolean attribute `whatever`. If you mean to conditionally ' +
+          'pass an attribute, use a ternary expression: {`whatever` ? value : undefined} ' +


Please make sure to read the messages you assert in tests. It looks like you were trying to adjust tests to match the wrong behavior in the code, rather than the other way around.

Sorry, my understanding was that the value being passed was the condition. So value should hold the attribute name instead of condition correct? It didn't make sense that whatever (holding the value false) could be an attribute. Thank you for your patience and help through this issue.

I’m sorry that I snapped. I had a bad day and shouldn’t have spoken to you with this tone. I apologize. In this test, whatever is the attribute name. Not the value. You can see if from the first sentence:

Received false for non-boolean attribute whatever.

Therefore, a condition like {whatever ? value : undefined} is not relevant to the user code. The user has something like whatever={condition && value} with condition being false. We want to tell the user to turn it into something like whatever={condition ? value : undefined}.

So I think ideally the messages would be:

If you get true:

expectDev(console.error.calls.argsFor(0)[0]).toContain( 'Received `true` for non-boolean attribute `whatever`.\n\n' + 'If you want `true` to appear in the DOM, cast it to a string. ' + 'For example, you can pass `whatever="true"` or `whatever={String(value)}` instead.' );

If you get false:

expectDev(console.error.calls.argsFor(0)[0]).toContain( 'Received `false` for non-boolean attribute `whatever`.\n\n' + 'If you want `false` to appear in the DOM, cast it to a string. ' + 'For example, you can pass `whatever="false"` or `whatever={String(value)}`.\n\n' + 'If you want to omit `whatever` based on a condition, use a ternary expression. ' + 'For example, you can pass `whatever={condition ? value : undefined}` ' + 'instead of `whatever={condition && value}`.' );

In these examples, whatever should of course refer to the attribute name, not literally "whatever". I only used whatever because that's what the test already uses.

I hope this is helpful and clarifies things!

No need to apologize, your message did not come off badly. I only apologized for making you revise this pr so many times because I did not grasp the whole picture. Yes, this is extremely helpful. Thank you.

Do you prefer:

`whatever={String(value)}`

or

`whatever={value.toString()}`

I feel the second option is a bit more verbose and easier to read.

I thought about the second one but it will throw for null/undefined. Might be unexpected. First one seems safer. Although on the other hand you probably don't want "undefined" or "null" as strings either.

I wish there was some concise way to express "stringify unless it's null/undefined".

I guess I like that value.toString() throws it it doesn't exist. If you mess it up you'll immediately realize it by the crash, instead of quietly using the wrong value. So let's suggest that.

gaearon · 2017-10-29T13:07:59Z

packages/react-dom/src/shared/ReactDOMUnknownPropertyHook.js

+      typeof value === 'boolean' &&
+      !DOMProperty.shouldAttributeAcceptBooleanValue(name)
+    ) {
+      if (value === true) {


Nit: we already know it's a boolean so can just write if (value)

gaearon · 2017-10-29T17:59:11Z

Thanks for the fixes!

I looked at it in practice, and I think it's a bit too noisy with backticks everywhere. Let's keep them around singular words (e.g. around attribute name), but remove them around fragments of code.

I also found the current messages too noisy and potentially misleading after all. Sorry about this—it takes a few iterations to get this right. Here's my new proposal.

For true:

expectDev(console.error.calls.argsFor(0)[0]).toContain(
  'Received `true` for non-boolean attribute `whatever`.\n\n' +
  'If you want to write it to the DOM, pass a string instead: ' +
  'whatever="true" or whatever={value.toString()}.'
);

For false:

expectDev(console.error.calls.argsFor(0)[0]).toContain(
  'Received `false` for non-boolean attribute `whatever`.\n\n' +
  'If you want to write it to the DOM, pass a string instead: ' +
  'whatever="false" or whatever={value.toString()}.\n\n' +
  'If you conditionally omit it with whatever={condition && value}, ' +
  'pass whatever={condition ? value : undefined} instead.'
);

I hope it’s not too much of a burden! I think these are clearer.

outdated

gaearon · 2017-10-31T13:02:38Z

I think this is good to go. Did a few minor changes. Thanks so much!

…11308) * Modified tests and corrected error message. facebook#3 * Fixed syntax issues. facebook#3 * Modified test. facebook#3 * Prettified. facebook#3 * Changed warning message to handle true and false boolean values. facebook#3 * Changed test to contain undefined instead of value. facebook#3 * Simplified branch structure. facebook#3 * Refactored branching logic. facebook#3 * Refactored falsy warning message and tests. facebook#3 * Changed condition to attribute name. facebook#3 * Refactored falsy and truthy warning messages with tests updated. facebook#3 * Added missing character. facebook#3 * Fixed warning message. facebook#3 * Cleared extra whitespace. facebook#3 * Refactored warning messages to be clear. facebook#3 * Prettified. facebook#3 * Grammar fix * Tweak unrelated warning The message didn't make sense because it appears for *any* attributes, not just numeric ones. * Tweak the message for more clarity * Add a special message for false event handlers * Add missing whitespace * Revert size changes

NicBonetto added 2 commits October 20, 2017 15:23

Modified tests and corrected error message. #3

2653595

Fixed syntax issues. #3

8de9a20

facebook-github-bot added the CLA Signed label Oct 20, 2017

NicBonetto added 2 commits October 20, 2017 15:44

Modified test. #3

4ce5b49

Prettified. #3

3d4724e

sebmarkbage previously requested changes Oct 21, 2017

View reviewed changes

NicBonetto added 2 commits October 24, 2017 15:42

Changed warning message to handle true and false boolean values. #3

449b98d

Changed test to contain undefined instead of value. #3

bb7978c

gaearon reviewed Oct 26, 2017

View reviewed changes

Simplified branch structure. #3

05ecf0a

gaearon reviewed Oct 26, 2017

View reviewed changes

Refactored branching logic. #3

e18a235

gaearon reviewed Oct 26, 2017

View reviewed changes

gaearon requested changes Oct 26, 2017

View reviewed changes

NicBonetto added 2 commits October 27, 2017 19:20

Refactored falsy warning message and tests. #3

9fc2b7f

Changed condition to attribute name. #3

ede38f3

gaearon reviewed Oct 28, 2017

View reviewed changes

NicBonetto added 4 commits October 28, 2017 18:31

Refactored falsy and truthy warning messages with tests updated. #3

ae6fcbf

Added missing character. #3

aada64c

Fixed warning message. #3

de26d9d

Cleared extra whitespace. #3

c7ee43d

gaearon reviewed Oct 29, 2017

View reviewed changes

NicBonetto added 2 commits October 29, 2017 15:09

Refactored warning messages to be clear. #3

2c19ea3

Prettified. #3

37207a0

gaearon approved these changes Oct 31, 2017

View reviewed changes

gaearon merged commit 544d5c7 into facebook:master Oct 31, 2017

gaearon mentioned this pull request Oct 31, 2017

Make invalid prop type warnings more specific if they are falsy #11289

Closed

renovate bot mentioned this pull request Feb 22, 2018

Update react monorepo packages to v16.2.0 mozilla/ensemble#28

Closed

This was referenced Mar 1, 2018

Update react-dom in / from 16.0.0 to 16.2.0 pcardune/redux-firebase-mirror#27

Open

Update react-test-renderer in / from 16.0.0 to 16.2.0 pcardune/redux-firebase-mirror#28

Open

This was referenced Mar 21, 2018

Update react to 16.3.2-abandoned sbardian/DebtTrackerAPI#15

Closed

Update react-dom to ^16.0.0-abandoned sbardian/DebtTrackerAPI#18

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixed invalid prop types error message to be more specific #11308

Fixed invalid prop types error message to be more specific #11308

NicBonetto commented Oct 20, 2017

NicBonetto commented Oct 20, 2017

sebmarkbage Oct 21, 2017 •

edited

Loading

NicBonetto commented Oct 25, 2017

gaearon left a comment •

edited

Loading

gaearon Oct 26, 2017

gaearon Oct 26, 2017

NicBonetto Oct 26, 2017 •

edited

Loading

gaearon Oct 26, 2017

gaearon Oct 26, 2017 •

edited

Loading

gaearon Oct 26, 2017 •

edited

Loading

gaearon Oct 26, 2017

gaearon Oct 26, 2017

gaearon Oct 26, 2017

gaearon Oct 26, 2017

gaearon commented Oct 28, 2017 •

edited

Loading

gaearon Oct 28, 2017

NicBonetto Oct 28, 2017 •

edited

Loading

gaearon Oct 28, 2017 •

edited

Loading

NicBonetto Oct 28, 2017

NicBonetto Oct 28, 2017 •

edited

Loading

gaearon Oct 29, 2017

gaearon Oct 29, 2017

gaearon commented Oct 29, 2017

gaearon commented Oct 31, 2017

Fixed invalid prop types error message to be more specific #11308

Fixed invalid prop types error message to be more specific #11308

Conversation

NicBonetto commented Oct 20, 2017

NicBonetto commented Oct 20, 2017

sebmarkbage Oct 21, 2017 • edited Loading

Choose a reason for hiding this comment

NicBonetto commented Oct 25, 2017

gaearon left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NicBonetto Oct 26, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon Oct 26, 2017 • edited Loading

Choose a reason for hiding this comment

gaearon Oct 26, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon commented Oct 28, 2017 • edited Loading

Choose a reason for hiding this comment

NicBonetto Oct 28, 2017 • edited Loading

Choose a reason for hiding this comment

gaearon Oct 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NicBonetto Oct 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon commented Oct 29, 2017

gaearon commented Oct 31, 2017

sebmarkbage Oct 21, 2017 •

edited

Loading

gaearon left a comment •

edited

Loading

NicBonetto Oct 26, 2017 •

edited

Loading

gaearon Oct 26, 2017 •

edited

Loading

gaearon Oct 26, 2017 •

edited

Loading

gaearon commented Oct 28, 2017 •

edited

Loading

NicBonetto Oct 28, 2017 •

edited

Loading

gaearon Oct 28, 2017 •

edited

Loading

NicBonetto Oct 28, 2017 •

edited

Loading