-
Notifications
You must be signed in to change notification settings - Fork 47k
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
Remove initOption special case #26595
Conversation
Comparing: ac43bf6...9159240 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
@@ -888,7 +888,7 @@ describe('ReactDOMSelect', () => { | |||
</select>, | |||
); | |||
|
|||
expect(node.value).toBe(''); | |||
expect(node.value).toBe('A Symbol!'); | |||
}); | |||
|
|||
it('treats initial Symbol defaultValue as an empty string', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These defaultValue tests are bad tests because they test what the current selection is with the first option, but since the first option is selected when there is no match, they don't fail if it just doesn't match.
0d9515b
to
11963c4
Compare
@@ -9,6 +9,12 @@ | |||
|
|||
'use strict'; | |||
|
|||
// Fix JSDOM. setAttribute is supposed to throw on things that can't be implicitly toStringed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a little hacky but it's making the TemporalLike objects throw without us explicitly tostringing in React which we shouldn't need to, since there can be Trusted Types involved. Maybe a newer JSDOM would help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we unset this in an afterAll so it's just for this file? Or move it to setupEnvironment.js (or setupTests.js? I don't know what the difference is)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it a new document for every test suite anyway? I think we rely on that anyway.
I wanted to colocate this fix so that we can choose to fix the tests instead if we need to.
85bfc2a
to
f5824b9
Compare
f5824b9
to
9159240
Compare
@@ -9,6 +9,12 @@ | |||
|
|||
'use strict'; | |||
|
|||
// Fix JSDOM. setAttribute is supposed to throw on things that can't be implicitly toStringed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we unset this in an afterAll so it's just for this file? Or move it to setupEnvironment.js (or setupTests.js? I don't know what the difference is)?
This traces back to #6449 and then another before that. I think that back then we favored the property over the attribute, and setting the property wouldn't be enough. However, the default path for these are now using attributes if we don't special case it. So we don't need it. The only difference is that we currently have a divergence for symbol/function behavior between controlled values that use the getToStringValue helpers which treat them as empty string, where as everywhere else they're treated as null/missing. Since this comes with a warning and is a weird error case, it's probably fine to change. DiffTrain build for [343a45f](343a45f)
This reverts commit 343a45f.
, facebook#26595, facebook#26596, facebook#26627 - Refactor some controlled component stuff (facebook#26573) - Don't update textarea defaultValue and input checked unnecessarily (facebook#26580) - Diff properties in the commit phase instead of generating an update payload (facebook#26583) - Move validation of text nesting into ReactDOMComponent (facebook#26594) - Remove initOption special case (facebook#26595) - Use already extracted values instead of reading off props for controlled components (facebook#26596) - Fix input tracking bug (facebook#26627)
- Refactor some controlled component stuff (#26573) - Don't update textarea defaultValue and input checked unnecessarily (#26580) - Diff properties in the commit phase instead of generating an update payload (#26583) - Move validation of text nesting into ReactDOMComponent (#26594) - Remove initOption special case (#26595) - Use already extracted values instead of reading off props for controlled components (#26596) - Fix input tracking bug (#26627) DiffTrain build for [ded4a78](ded4a78)
- Refactor some controlled component stuff (#26573) - Don't update textarea defaultValue and input checked unnecessarily (#26580) - Diff properties in the commit phase instead of generating an update payload (#26583) - Move validation of text nesting into ReactDOMComponent (#26594) - Remove initOption special case (#26595) - Use already extracted values instead of reading off props for controlled components (#26596) - Fix input tracking bug (#26627)
This traces back to facebook#6449 and then another before that. I think that back then we favored the property over the attribute, and setting the property wouldn't be enough. However, the default path for these are now using attributes if we don't special case it. So we don't need it. The only difference is that we currently have a divergence for symbol/function behavior between controlled values that use the getToStringValue helpers which treat them as empty string, where as everywhere else they're treated as null/missing. Since this comes with a warning and is a weird error case, it's probably fine to change.
This traces back to #6449 and then another before that. I think that back then we favored the property over the attribute, and setting the property wouldn't be enough. However, the default path for these are now using attributes if we don't special case it. So we don't need it. The only difference is that we currently have a divergence for symbol/function behavior between controlled values that use the getToStringValue helpers which treat them as empty string, where as everywhere else they're treated as null/missing. Since this comes with a warning and is a weird error case, it's probably fine to change. DiffTrain build for commit 343a45f.
This traces back to #6449 and then another before that.
I think that back then we favored the property over the attribute, and setting the property wouldn't be enough. However, the default path for these are now using attributes if we don't special case it. So we don't need it.
The only difference is that we currently have a divergence for symbol/function behavior between controlled values that use the getToStringValue helpers which treat them as empty string, where as everywhere else they're treated as null/missing.
Since this comes with a warning and is a weird error case, it's probably fine to change.