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

Enable warnings for the defaultValue prop #13360

Closed
wants to merge 5 commits into from
Closed

Enable warnings for the defaultValue prop #13360

wants to merge 5 commits into from

Conversation

raunofreiberg
Copy link
Contributor

Somewhat related to #11734.

I started off with adding warnings for assigning symbols and functions to the defaultValue prop (ultimately resolving TODOs in ReactDOMInput-test.js), then quickly realized that there are a few cases that don't currently warn, so I decided to go ahead and cover those as well. For i.e, assigning a boolean to defaultValue currently does not warn, but could, in order to prevent potential pitfalls or misconceptions.

@@ -214,12 +214,6 @@ if (__DEV__) {
return true;
}

// Now that we've validated casing, do not validate
// data types for reserved props
if (isReserved) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I decided to remove this since the shouldRemoveAttributeWithWarning function already duplicates this logic internally.

@@ -115,7 +115,13 @@ export function shouldRemoveAttributeWithWarning(
propertyInfo: PropertyInfo | null,
isCustomComponentTag: boolean,
): boolean {
if (propertyInfo !== null && propertyInfo.type === RESERVED) {
// Do not validate data types for reserved props
// (excluding defaultValue)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a bit odd. Maybe we shouldn’t treat it as reserved?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, but wouldn't we then be committing unwanted attributes to the DOM?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don’t know. You tell me what would happen :-)

Copy link
Contributor Author

@raunofreiberg raunofreiberg Aug 10, 2018

Choose a reason for hiding this comment

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

I went ahead and uncommented defaultValue from the list of reserved properties and a few test suites started to fail in a similar manner (for e.g, ReactDOMServerIntegrationForms), confirming what I was expecting.

E.g.

image

This seems to only affect SSR, client side cases seem to pass, for e.g:

const div = document.createElement('div');
const node = ReactDOM.render(<textarea defaultValue="1" />, div);
expect(node.getAttribute('defaultValue')).toBe(null);

I'm not too certain nor familiar with how strict we want to be about reserved properties (committing them to the DOM is definitely out of the question, I would assume).

Maybe we can keep the attribute reserved as is, but instead add another key to PropertyInfo (e.g. boolean shouldWarnInDev) to enable warnings for custom properties. This way the condition that you mentioned above would become:

if (
  propertyInfo !== null &&
  propertyInfo.type === RESERVED &&
  !propertyInfo.shouldWarnInDev
) {
  return false;
}

Also, enabling warnings for other reserved properties would be a breeze this way, IMHO :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added a proof of concept commit to illustrate my approach better.

@stale
Copy link

stale bot commented Jan 10, 2020

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jan 10, 2020
@stale
Copy link

stale bot commented Jan 17, 2020

Closing this pull request after a prolonged period of inactivity. If this issue is still present in the latest release, please ask for this pull request to be reopened. Thank you!

@stale stale bot closed this Jan 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed Resolution: Stale Automatically closed due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants