mirror of
https://github.com/facebook/react.git
synced 2026-02-25 22:04:59 +00:00
8a09a2fc53
* Updates inside controlled events (onChange) are sync even in async mode This guarantees the DOM is in a consistent state before we yield back to the browser. We'll need to figure out a separate strategy for other interactive events. * Don't rely on flushing behavior of public batchedUpdates implementation Flush work as an explicit step at the end of the event, right before restoring controlled state. * Interactive updates At the beginning of an interactive browser event (events that fire as the result of a user interaction, like a click), check for pending updates that were scheduled in a previous interactive event. Flush the pending updates synchronously so that the event handlers are up-to-date before responding to the current event. We now have three classes of events: - Controlled events. Updates are always flushed synchronously. - Interactive events. Updates are async, unless another a subsequent event is fired before it can complete, as described above. They are also slightly higher priority than a normal async update. - Non-interactive events. These are treated as normal, low-priority async updates. * Flush lowest pending interactive update time Accounts for case when multiple interactive updates are scheduled at different priorities. This can happen when an interactive event is dispatched inside an async subtree, and there's an event handler on an ancestor that is outside the subtree. * Update comment about restoring controlled components