-
Notifications
You must be signed in to change notification settings - Fork 46.9k
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
Use explicit pass for restoring controlled state instead of asap #8176
Conversation
@@ -452,6 +455,12 @@ function makeSimulator(eventType) { | |||
EventPluginHub.enqueueEvents(event); | |||
EventPluginHub.processEventQueue(true); | |||
}); | |||
// Normally extractEvent enqueues a state restore, but we'll just always do | |||
// that. |
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.
Why not leave it in ChangeEventPlugin only for consistency with the non-test env?
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 bypasses the ChangeEventPlugin and creates its own synthetic event. So it doesn't go through that logic.
How would you suggest that I leave it in ChangeEvent? Expose something only for testing?
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 got it, I was thinking this was SimulateNative. I'm good with this.
This gets rid of the first class ReactUpdates.asap scheduling. Instead of scheduling a first class function to invoke later, I introduce an explicit phase for restoring controlled state after dispatching events. We assume that the deepest event target is the thing that needs its state restored.
We're now not using anything special about onChange handling in the wrappers. Yay!
…ebook#8176) * Use explicit pass for restoring controlled state instead of asap This gets rid of the first class ReactUpdates.asap scheduling. Instead of scheduling a first class function to invoke later, I introduce an explicit phase for restoring controlled state after dispatching events. We assume that the deepest event target is the thing that needs its state restored. * Drop special cases for onChange in wrappers We're now not using anything special about onChange handling in the wrappers. Yay!
This gets rid of the first class ReactUpdates.asap scheduling. Instead of scheduling a first class function to invoke later, I introduce an explicit phase for restoring controlled state after dispatching events.
We assume that the deepest event target is the thing that needs its state restored.