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

bug fix on input radio #11227

Merged
merged 9 commits into from Nov 19, 2017

Conversation

Projects
None yet
4 participants
@landvibe
Contributor

landvibe commented Oct 14, 2017

Fixed: #7630

The PR#7333 made this issue.
And now there is no validation warning that PR#7333 is mentioning.
I think React 16 resolved the validation warning issue, so I reverted it to the previous of PR#7333.
I also added a test case for #7630

@landvibe landvibe referenced this pull request Oct 15, 2017

Open

Umbrella: React DOM Bugs #11097

11 of 28 tasks complete
@jquense

This comment has been minimized.

Show comment
Hide comment
@jquense

jquense Oct 26, 2017

Collaborator

So i'm not sure that the unit tests will catch this ( @nhunzaker might know) effectively give that it's a browser specific warning? I think we should move the original unit test in #7333 to a DOM fixture and ensure that it works. I think we also need understand why this was fixed inadvertantly in v16 before merging

Collaborator

jquense commented Oct 26, 2017

So i'm not sure that the unit tests will catch this ( @nhunzaker might know) effectively give that it's a browser specific warning? I think we should move the original unit test in #7333 to a DOM fixture and ensure that it works. I think we also need understand why this was fixed inadvertantly in v16 before merging

landvibe added some commits Oct 27, 2017

landvibe landvibe
roll back previous commit
make radio's checked updated before the name
@landvibe

This comment has been minimized.

Show comment
Hide comment
@landvibe

landvibe Oct 27, 2017

Contributor

@jquense

I tested https://jsfiddle.net/97gr5e65/1/ made by @aweary.
And I realized React 16 did not resolve the validation warning.
So I don't think it is a good idea to edit @@nhunzaker's code.
And I started over.

After some debugging, I found an interesting point.
When we edit a radio's name with checked===true, browser makes another radio's checked false.
In the middle of an update, it is possible to have multiple checked===true.

Let me explain it with the test case I added.
There are two radio inputs.

initial state:
radio1: {
name: 'firstName',
checked: false,
}
radio2: {
name: 'firstName',
checked: true,
}

promising state after update:
radio1: {
name: 'secondName',
checked: true,
}
radio2: {
name: 'secondName',
checked: false,
}

step1, update radio1:
radio1: {
name: 'secondName',
checked: true,
}
radio2: {
name: 'firstName',
checked: true,
}

step2-1, update radio2's name:
radio1: {
name: 'secondName',
checked: false, // whoops...
}
radio2: {
name: 'secondName',
checked: true,
}

I think if we update checked first, it would be ok
So I added updateChecked function.

Contributor

landvibe commented Oct 27, 2017

@jquense

I tested https://jsfiddle.net/97gr5e65/1/ made by @aweary.
And I realized React 16 did not resolve the validation warning.
So I don't think it is a good idea to edit @@nhunzaker's code.
And I started over.

After some debugging, I found an interesting point.
When we edit a radio's name with checked===true, browser makes another radio's checked false.
In the middle of an update, it is possible to have multiple checked===true.

Let me explain it with the test case I added.
There are two radio inputs.

initial state:
radio1: {
name: 'firstName',
checked: false,
}
radio2: {
name: 'firstName',
checked: true,
}

promising state after update:
radio1: {
name: 'secondName',
checked: true,
}
radio2: {
name: 'secondName',
checked: false,
}

step1, update radio1:
radio1: {
name: 'secondName',
checked: true,
}
radio2: {
name: 'firstName',
checked: true,
}

step2-1, update radio2's name:
radio1: {
name: 'secondName',
checked: false, // whoops...
}
radio2: {
name: 'secondName',
checked: true,
}

I think if we update checked first, it would be ok
So I added updateChecked function.

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Oct 28, 2017

Collaborator

Hey everyone. Sorry! I was out of town and lost track. I'll start checking this out.

Collaborator

nhunzaker commented Oct 28, 2017

Hey everyone. Sorry! I was out of town and lost track. I'll start checking this out.

@nhunzaker

Tested in:

  • IE9-11
  • Safari Desktop 7.1, 8, 11
  • Safari iOS 9
  • Firefox 47, 56
  • Chrome 42, 62

This checks out!

@jquense I made a test fixture to manually verify this: nhunzaker@f18c4c4

@landvibe Great work spotting this! Do you mind if I push this fixture to your PR?

Still, we need to figure out why restoreControlledState isn't firing in this instance. Right now, I see that as the root of the problem.

Alternatively, could we just call updateNamedCousins where this PR now has updateChecked? Is there an advantage to one over the other?

@landvibe

This comment has been minimized.

Show comment
Hide comment
@landvibe

landvibe Nov 7, 2017

Contributor

@nhunzaker
I think updateChecked is more efficient than updateNamedCousins.
updateChecked just calls setValueForProperty once, but updateNamedCousins calls it group.length times per each updated node

new commit with your fixture

Contributor

landvibe commented Nov 7, 2017

@nhunzaker
I think updateChecked is more efficient than updateNamedCousins.
updateChecked just calls setValueForProperty once, but updateNamedCousins calls it group.length times per each updated node

new commit with your fixture

@nhunzaker

Sorry for the delay. I had to spend some time figuring out what updateNamedCousins is actually doing. It looks like this is necessary for controlled radios so that you can programmatically prevent them from changing via state (like not toggling state in a change handler).

This looks good, I'd just like for the conditions for applying updateChecked to mirror that of updateNamedCousins, which I've laid out in the comments.

@landvibe

This comment has been minimized.

Show comment
Hide comment
@landvibe

landvibe Nov 13, 2017

Contributor

@nhunzaker applied your comment

Contributor

landvibe commented Nov 13, 2017

@nhunzaker applied your comment

@nhunzaker

Looks good! I'm waiting on a build to do some final testing before merging. Thank you for sticking with me!

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Nov 19, 2017

Collaborator

Verified in:

  • IE 9/10/11
  • Edge 14/15/16
  • Chrome 62, 49, 41
  • Safari 7.1, 8, 9.1, 10.1, 11
  • iOS 7, 8, 9, 10.2, 11.1
  • Chrome for Android (latest)
  • Firefox 56, 52 (ESR), 47 (Former ESR)
  • Opera 41, 49

😅 (When am I finally going to automate this...)

Thank you for sending this out. I apologize it took this long. This is a fantastic find!

Collaborator

nhunzaker commented Nov 19, 2017

Verified in:

  • IE 9/10/11
  • Edge 14/15/16
  • Chrome 62, 49, 41
  • Safari 7.1, 8, 9.1, 10.1, 11
  • iOS 7, 8, 9, 10.2, 11.1
  • Chrome for Android (latest)
  • Firefox 56, 52 (ESR), 47 (Former ESR)
  • Opera 41, 49

😅 (When am I finally going to automate this...)

Thank you for sending this out. I apologize it took this long. This is a fantastic find!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment