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

Remove pendingUpdate optimization in ReactDOMSelect #8175

Merged
merged 1 commit into from
Nov 2, 2016

Conversation

sebmarkbage
Copy link
Collaborator

This removes an optimization that avoids call update on ReactDOMSelect
twice in an onChange event.

2601b6a#commitcomment-19643403

None of the other controlled components do this. The only reason to do it
here is because of the loop.

I'd like to remove this because I'd like to remove all the side-effects
that happen in onChange, other than user defined behavior. I'd also like to
get rid of state that track sequences. It is easier if everything is just
diffing.

Alternatively I can store the previous value that we processed and only
reprocess if the value has changed. However, that would requires the array
for multiple values to be immutable and I don't think we enforce that
right now.

In Fiber, I believe that we'll be able to batch both these updates into a
single commit.

This removes an optimization that avoids call update on ReactDOMSelect
twice in an onChange event.

facebook@2601b6a#commitcomment-19643403

None of the other controlled components do this. The only reason to do it
here is because of the loop.

I'd like to remove this because I'd like to remove all the side-effects
that happen in onChange, other than user defined behavior. I'd also like to
get rid of state that track sequences. It is easier if everything is just
diffing.

Alternatively I can store the previous value that we processed and only
reprocess if the value has changed. However, that would requires the array
for multiple values to be immutable and I don't think we enforce that
right now.

In Fiber, I believe that we'll be able to batch both these updates into a
single commit.
expect(() => ReactTestUtils.Simulate.change(node)).not.toThrow(
"Cannot set property 'pendingUpdate' of null"
);
expect(() => ReactTestUtils.Simulate.change(node)).not.toThrow();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We should never test for absence of a particular error message since that might cover up errors when messages change.

@syranide
Copy link
Contributor

syranide commented Nov 2, 2016

I thought about this some more, it's worth checking whether focus still behaves correctly, i.e. does focusing it and selecting stuff via the keyboard still work correctly. Also, does anyone know why we're using asap here to begin with? It seems like it should be possible to simplify this.

@sebmarkbage
Copy link
Collaborator Author

sebmarkbage commented Nov 2, 2016

@syranide For context see where I replace controlled work in the event handlers: #8176

The motivation is that I want to make all event listeners lazy instead of storing them during render.

I don't know if asap was necessary for selects but it was at least for inputs: #1698

acusti pushed a commit to brandcast/react that referenced this pull request Mar 15, 2017
This removes an optimization that avoids call update on ReactDOMSelect
twice in an onChange event.

facebook@2601b6a#commitcomment-19643403

None of the other controlled components do this. The only reason to do it
here is because of the loop.

I'd like to remove this because I'd like to remove all the side-effects
that happen in onChange, other than user defined behavior. I'd also like to
get rid of state that track sequences. It is easier if everything is just
diffing.

Alternatively I can store the previous value that we processed and only
reprocess if the value has changed. However, that would requires the array
for multiple values to be immutable and I don't think we enforce that
right now.

In Fiber, I believe that we'll be able to batch both these updates into a
single commit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants