Experimental Event API: Redesign event responder propagation #15408
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
ReactDOM: size: -0.1%, gzip: -0.1% Details of bundled changes.Comparing: a30e7d9...157f4cb react-dom
react-events
Generated by 🚫 dangerJS |
trueadm
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims at tackling a class of issues, confusion and bugs with how event responder propagate in the different phases and how
stopPropagationworks. The previous implementation didn't correctly ensure event components in the capture phase were fired in the right order. This PR revamps the entire process, cleaning up code along the way and improving performance significantly compared to before.This also fixes a bunch of bugs along the way, which now have tests added to ensure we don't regress. Another big change is that it is expected the the event responder
onEventreturns abooleanindicating if the event module itself should prevent propagation after. Rather than before, where you'd usedispatchStopPropagation, which didn't make a lot of sense. Furthermore, the respondereventobject passed to the callbacks (likeonEvent) now has aphaseinteger property. The phase property indicates what the current phase is:0: root phase1: bubble phase2: capture phaseThe ordering of these phases, when events come in:
Capture target event types->Bubble target event types->Root event typesThis can be used to properly dispatch events in their relative phases, rather than passing
captureon the config object ofdispatchEvent. So, if you want to dispatch an event in the capture phase, you need to check the current phase that the eventonEventis in and ensure you're in the same phase as what you want to dispatch in.I also removed the new responder event system from using the plugin event system's bookkeeping logic – it was never actually needed and just added overhead on each event pass. So now the fork for the different event systems happens in
dispatchEvent.