* Remove capturePhaseEvents and separate events by bubbling
WIP
Refine all logic
Revise types
Fix
Fix conflicts
Fix flags
Fix
Fix
Fix test
Revise
Cleanup
Refine
Deal with replaying
Fix
* Add non delegated listeners unconditionally
* Add media events
* Fix a previously ignored test
* Address feedback
Co-authored-by: Dan Abramov <dan.abramov@me.com>
* Pass event time to markRootUpdated
Some minor rearranging so that eventTime gets threaded through. No
change in behavior.
* Track event times per lane on the root
Previous strategy was to store the event time on the update object
and accumulate the most recent one during the render phase.
Among other advantages, by tracking them on the root, we can read the
event time before the render phase has finished.
I haven't removed the `eventTime` field from the update object yet,
because it's still used to compute the timeout. Tracking the timeout
on the root is my next step.
* Set current update lane priority for user blocking events
* Update to use LanePriority and not use runWithPriority
* Remove unused imports
* Fix tests, and I missed ReactDOMEventListener
* Fix more tests
* Add try/finally and hardcode lane priorities instead
* Also hard code InputContinuousLanePriority in tests
* Remove un-needed exports
* Comment rollbacks
* Make enableSchedulingProfiler flag static
* Copied debug tracing and scheduler profiling to .new fork and updated feature flags
* Move profiler component stacks behind a feature flag
* Effects list rewrite
* Improved deletions approach
Process deletions as we traverse the tree during commit, before we process other effects. This has the result of better mimicking the previous sequencing.
* Made deletions field nullable
* Revert (no longer necessary) change to ReactNative test
* Eagerly set Deletions effect on Fiber when adding child to deletions array
* Initialize deletions array to null
* Null out deletions array instead of splicing 🤡
* Removed TODO comment
* Initial exploration on a did-bailout flag
* fixed the rest of the bugs
* Rolled temporary didBailout attribute into subtreeTag
* addressed comments
* Removed DidBailout subtree tag
* Removed stale comment
* use while loop instead of recursion for siblings
* move bailout flag from while loop
* Removed some unnecessary Deletion effectTags from children
* Move Deletion effect assignment to deletions array initialization
Co-authored-by: Luna <lunaris.ruan@gmail.com>
DevTools isn't being downloaded like typical JavaScript, so bundle size concerns don't apply. Parsing is still a consideration (so I'm open for discussion here) but I think this change would provide a couple of benefits:
* People are more likely to *actually read* non-minified source code when e.g. a breakpoint is hit (as with the recent debugger statement)
* Component stacks will be easier to parse on bug reports
* Make enableSchedulingProfiler static for profiling+experimental builds
* Copied debug tracing and scheduler profiling to .new fork
* Updated test @gate conditions
Now that Suspense retries have their own dedicated set of lanes
(#19287), we can determine if a render includes only retries by checking
if its lanes are a subset of the retry lanes.
Previously we inferred this by checking
`workInProgressRootLatestProcessedEventTime`. If it's not set, that
implies that no updates were processed in the current render, which
implies it must be a Suspense retry. The eventual plan is to get rid of
`workInProgressRootLatestProcessedEventTime` and instead track event
times on the root; this change is one the steps toward that goal.
The relevant tests were originally added in #15769.
Some clean up to make the Lanes type easier to maintain.
I removed the "start" and "end" range markers; they don't provide any
information that isn't already encoded in the bitmask for each range,
and there's no computation saved compared to the
`pickArbitraryLane` function.
The overall algorithm is largely the same but I did tweak some of the
details. For example, if the lanes for a given priority are already
being worked on, the previous algorithm would assign to the next
available lane, including the dedicated hydration lanes that exist
in between each priority.
The updated algorithm skips over the hydration lanes and goes to the
next priority level. In the rare instance when all the non-Idle update
lanes are occupied, it will pick an abitrary default lane. This will
have the effect of invalidating the current work-in-progress, and
indicates a starvation scenario.
Eventually, if there are too many interruptions, the expiration time
mechanism will kick in and force the update to synchronously finish.