-
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
Fix form reset for uncontrolled select elements #11057
Fix form reset for uncontrolled select elements #11057
Conversation
Deploy preview ready! Built with commit 2ee1ba7 |
@@ -103,6 +107,9 @@ function updateOptions( | |||
for (let i = 0; i < options.length; i++) { | |||
if (options[i].value === selectedValue) { | |||
options[i].selected = true; | |||
if (setDefaultSelected) { | |||
options[i].defaultSelected = true; |
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.
perhaps this should be set once on mount? That is a bit iffy i guess. Ostensibly defaultValue
is set once for inputs and changing it after that is a noop for the life of the component. It seems like now tho you can set it, change it and reset the form and it'll use the new value. That may not be worth the complexity to address, but it opens up a new inconsistency perhaps.
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.
Ostensibly defaultValue is set once for inputs and changing it after that is a noop for the life of the component.
That isn't the case, as far as I've seen. Here's an example that you can update defaultValue
and a form reset will reset to the new defaultValue
option. That happens in ReactDOMFiberInput.updateWrapper
here. In both cases, updating .defaultValue
is guarded by a loose null
check for value
first, so I think it should be consistent?
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.
ah ok, so it's consistent with the other input reset behavior sorry. carry on then :P
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 looks good to me. It is frustrating that there is not a higher level DOM API for this.
Just to be sure: does form reset trigger a change event on selects? It should not, at least it does not for inputs last i checked, but i don't believe in consistent DOM APIs anymore
Do we know yet if |
@jquense I tested in IE9, and the latest Chrome, Firefox, and Safari on macOS. It would be great if we could run through the fixtures in some browsers. You can find them here: http://uncontrolled-select-reset.surge.sh/
@nhunzaker from what I saw, it doesn't trigger a change event, so it should be consistent. |
I ran it through on android 4.4, old IOS, edge and safari 8 and 👍 |
Finally got to testing. Tried to fill in the gaps:
|
Anything blocking this? |
Nothing that I see. @aweary this is checking out for me everywhere. Any final concerns before merging? |
@gaearon had mentioned that @sebmarkbage might have some thoughts on this, so if it looks good to him then 🚀 |
Resolves #11010
defaultSelected
will now be set on the select's option's elements based on the value(s) indefaultValue
. Added a test fixture, too.