forked from facebook/react
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Elohimsupremes #4
Open
ELOHIMSUPREMES
wants to merge
4,584
commits into
zpao:valuetest
Choose a base branch
from
ELOHIMSUPREMES:master
base: valuetest
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
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
…cebook#15179) * Add part of the event responder system
* Adds Press and Hover event modules + more features to the Event Responder System
* Fix circular module imports causing file size increase
This will be on by default in open source for the next major.
…erer (facebook#15242) * Adds React event component and React event target support to SSR renderer
The 'longpress' event is dispatched during a press interaction, rather than after it has ended. The 'longPressCancelsPress' prop can be used to prevent 'press' being dispatched if 'longpress' has already been dispatched.
* Add rest of event modules + small fixes
…ook#15256) Make sure that `onPressChange` is only called if `longPressCancelsPress` is `false`. And make sure that `onLongPressChange` is called when a long press ends.
Note: this is for an experimental event API that we're testing out internally at Facebook. Fixes a regression in f4625f5
* Make setNativeProps a no-op with Fabric renderer * Remove unnecessary __DEV__ check
* ReactNative's ref.measureLayout now takes a ref * Use Object as the additional param type * Remove unnecessary whitespace * Not supporting ref in mixin or subclass
Note: this is for an experimental event API that we're testing out internally at Facebook. * onPressIn -> onPressStart * onPressOut -> onPressEnd * longPressCancelsPress -> onLongPressShouldCancelPress
As far as I can tell this build is broken. Let's fix or delete. If I can't test, I can't patch it up when I break it.
…cebook#15283) * Rename hover props in experimental event API and write unit tests
* Add PressProps type to event module * Move default Press event delays to constants * Fix right-click press check for Safari * Prettier and Linter * Use event.key in press responder event.keyCode is a deprecated API * Remove unused props from Press event module
* Add Press responder event tests Behavior being tested takes cues from React Native's Pressability. A couple of these tests fail and require the Press implementation to be patched.
…acebook#15292) * Remove warning for event targets being direct children of event component * Addressed feedback and added more test coverage + warnings
…ok#15295) * Refactor event object creation for the experimental event API
We instead assume a 150ms duration.
This took a while, but I'm happy I went through it. Some key moments - recursively flushing effects, flushing microtasks on each async turn, and my team's uncompromising philosophy on code reuse. Really happy with this. I still want to expand test coverage, and I have some more small related todos, but this is good to land. On to the next one. Soundtrack to landing this - https://open.spotify.com/track/0MF8I8OUo8kytiOo8aSHYq?si=gSWqUheKQbiQDXzptCXHTg * hacked up act(async () => {...}) * move stuff around * merge changes * abstract .act warnings and stuff. all renderers. pass all tests. * move testutils.act back into testutils * move into scheduler, rename some bits * smaller bundle * a comment for why we don't do typeof === 'function' * fix test * pass tests - fire, prod * lose actContainerElement * tighter * write a test for TestRenderer it's an odd one, because not only does sync act not flush effects correctly, but the async one does (wut). verified it's fine with the dom version. * lint * rewrote to move flushing logic closer to the renderer the scheduler's `flushPassiveEffects` didn't work as expected for the test renderer, so I decided to go back to the hack (rendering a dumb container) This also makes reactdom not as heavy (by a few bytes, but still). * move it around so the delta isn't too bad * cleanups fix promise chaining propagate errors correctly test for thenable the 'right' way more tests! tidier! ponies! * Stray comment * recursively flush effects * fixed tests * lint, move noop.act into react-reconciler * microtasks when checking if called, s/called/calledLog, cleanup * pass fb lint we could have globally changed our eslint config to assume Promise is available, but that means we expect a promise polyfill on the page, and we don't yet. this code is triggered only in jest anyway, and we're fairly certain Promise will be available there. hence, the once-off disable for the check * shorter timers, fix a test, test for Promise * use global.Promise for existence check * flush microtasks * a version that works in browsers (that support postMessage) I also added a sanity fixture inside fixtures/dom/ mostly for me. * hoist flushEffectsAndMicroTasks * pull out tick logic from ReactFiberScheduler * fix await act (...sync) hanging - fix a hang when awaiting sync logic - a better async/await test for test renderer * feedback changes - use node's setImmediate if available - a warning if MessageChannel isn't available - rename some functions * pass lint/flow checks (without requiring a Promise polyfill/exclusion) * prettier the prettiest, even. * use globalPromise for the missed await warning * __DEV__ check for didWarnAboutMessageChannel * thenables and callbacks instead of promises, pass flow/lint * tinier. better. - pulled most bits out of FiberScheduler - actedUpdates uses callbacks now * pass build validation * augh prettier * golfing 7 more chars * Test that effects are not flushed without also flushing microtasks * export doesHavePendingPassiveEffects, nits * createAct() * dead code * missed in merge? * lose the preflushing bits * ugh prettier * removed `actedUpdates()`, created shared/actingUpdatesScopeDepth * rearrange imports so builds work, remove the hack versions of flushPassiveEffects * represent actingUpdatesScopeDepth as a tuple [number] * use a shared flag on React.__SECRET... * remove createAct, setup act for all relevant renderers * review feedback shared/enqueueTask import ReactSharedInternals from 'shared/ReactSharedInternals'; simpler act() internals ReactSharedInternals.ReactShouldWarnActingUpdates * move act() implementation into createReactNoop * warnIfNotCurrentlyActingUpdatesInDev condition check order
…kage (facebook#15151) * Rewrite ReactFiberScheduler Adds a new implementation of ReactFiberScheduler behind a feature flag. We will maintain both implementations in parallel until the new one is proven stable enough to replace the old one. The main difference between the implementations is that the new one is integrated with the Scheduler package's priority levels. * Conditionally add fields to FiberRoot Some fields only used by the old scheduler, and some by the new. * Add separate build that enables new scheduler * Re-enable skipped test If synchronous updates are scheduled by a passive effect, that work should be flushed synchronously, even if flushPassiveEffects is called inside batchedUpdates. * Passive effects have same priority as render * Revert ability to cancel the current callback React doesn't need this anyway because it never schedules callbacks if it's already rendering. * Revert change to FiberDebugPerf Turns out this isn't neccessary. * Fix ReactFiberScheduler dead code elimination Should initialize to nothing, then assign the exports conditionally, instead of initializing to the old exports and then reassigning to the new ones. * Don't yield before commit during sync error retry * Call Scheduler.flushAll unconditionally in tests Instead of wrapping in enableNewScheduler flag.
The previous naming scheme used the name of the resulting bundle file. However, there are cases where multiple bundles have the same filename. This meant whichever bundle finishes last overwrites the previous ones with the same name. The updated naming scheme is `bundle-sizes-<CI_NODE_INDEX>.json`. Instead of generating a separate info file per bundle, it now creates one per process.
* Track most recent commit time of a fallback globally This value is going to be used to avoid committing too many fallback states in quick succession. It doesn't really matter where in the tree that happened. This means that we now don't really need the concept of SuspenseState other than has a flag. It could be made cheaper/simpler. * Change suspense heuristic This now eagerly commits non-delayed suspended trees, unless they're only retries in which case they're throttled to 500ms. * Restart early if we're going to suspend later * Use the local variable where appropriate * Make ReactLazy tests less specific on asserting intermediate states They're not testing the exact states of the suspense boundaries, only the result. I keep assertions that they're not already resolved early. * Adjust Profiler tests to the new heuristics * Update snapshot tests for user timing tests I also added a blank initial render to ensuree that we cover the suspended case. * Adjust Suspense tests to account for new heuristics Mostly this just means render the Suspense boundary first so that it becomes an update instead of initial mount. * Track whether we have a ping on the currently rendering level If we get a ping on this level but have not yet suspended, we might still suspend later. In that case we should still restart. * Add comment about moving markers We should add this to throwException so we get these markers earlier. I've had to rewrite tests that test restarting to account for the delayed restarting heuristic. Ideally, we should also be able to restart from within throwException if we're already ready to restart. Right now we wait until the next yield. * Add test for restarting during throttled retry * Add test that we don't restart for initial render * Add Suspense Heuristics as a comment in Throw
* Fix issue with Tab+alt not being considered as isGlobalFocusVisible candidate on Mac * Add test for Tab+alt on Mac setting pointerType: "keyboard" on a focus event
`keypress` is a deprecated event.
WorkPhase is an enum that represents the currently executing phase of the React update -> render -> commit cycle. However, in practice, it's hard to use because different "phases" can be nested inside each other. For example, the commit phase can be nested inside the "batched phase." This replaces WorkPhase with a different concept: ExecutionContext. ExecutionContext is a bitmask instead of an enum. It represents a stack of React entry points. For example, when `batchedUpdates` is called from inside an effect, the ExecutionContext is `BatchedContext | CommitContext`.
Events were previously described as "interactive" or "non-interactive".
shouldflushDiscreteUpdates -> shouldFlushDiscreteUpdates
If an event in the old system is dispatched synchronously within an event from the new system, or vice versa, and the inner event is a discrete update, React should not flush pending discrete updates before firing the inner event's handlers, even if the outer event is not discrete. Another way of saying this is that nested events should never force React to flush discrete updates. Arguably, if the outer event is not a discrete event, then the inner event _should_ flush the pending events. However, that would be a breaking change. I would argue this isn't so bad, however, given that nested events are pretty rare. They don't fit nicely into our event model regardless, since we don't support nested React renders. In the future we should consider warning when events are nested.
In Exhaustive Deps check for react-hooks don't warn if the dependency is a Flow type variable.
…sion (facebook#15786) This commit is a follow-up to facebook#15604, which explains more of the rationale behind moving React Native to path-based imports and the work needed in the React repository. In that linked PR, the generated renderers were updated but not the shims; this commit updates the shims. The problem is that FB needs a different copy of the built renderers than the OSS versions so we need a way for FB code to import different modules than in OSS. This was previously done with Haste, but with the removal of Haste from RN, we need another mechanism. Talking with cpojer, we are using a `.fb.js` extension that Metro can be configured to prioritize over `.js`. This commit generates FB's renderers with the `.fb.js` extension and OSS renderers with just `.js`. This way, FB can internally configure Metro to use the `.fb.js` implementations and OSS will use the `.js` ones, letting us swap out which implementation gets bundled. Test Plan: Generated the renderers and shims with `yarn build` and then verified that the generated shims don't contain any Haste-style imports. Copied the renderers and shims into RN manually and launched the RNTester app to verify it loads end-to-end. Added `.fb.js` to the extensions in `metro.config.js` and verified that the FB-specific bundles loaded.
Compare the viewport-relative coordinates of getBoundingClientRect with those of the event's client{X,Y} values. This fixes press within scrollable nodes.
…nuous (facebook#15811) * [Events] Add EventPriority enum React DOM's DispatchConfig for synthetic events has an `isDiscrete` field that affects how updates triggered by an event are scheduled. Events are either discrete or continuous. This commit adds an additional type of configuration where an event has user-blocking priority, but is not discrete. E.g. updates triggered by hover are more important than the default, but they don't need to be processed serially. Because there are now three types of event priority instead of two, I've replaced the `isDiscrete` boolean with an enum: `eventPriority`. This commit implements the new enum value but does not change any behavior. I'll enable it behind a feature flag in the next commit. I've only implemented this in the legacy event system. I'll leave Flare for a follow-up. * enableUserBlockingEvents feature flag Adds a feature flag to increase the priority of events like `mouseover`, without making them discrete.
* Same as previous commit, but for Flare I don't know what the public API for setting the event priority should be. Right now it accepts a numeric enum, but is this what we want? Maybe it should be a string enum? I've punted on this for now. * Add test for hover events
) * Remount classes during hot reload * Fix a crash when Hook isn't in scope inside the signature * Minor tweaks * Support a comment annotation to force state reset * Refactoring: pass a function instead of WeakMap This hides the implementation a little bit and reduces how much React knows about the underlying mechanism. * Refactor: use forceReset to remount unknown Hooks We already have the logic to reset a component, so let's just reuse it instead of that special case.
* Split the signature call into two calls This adds a render-time signature call by making __signature__ curried. We need both calls. The init time tells us which type has which signature. The render time call says when's a good time to capture the lazy Hooks tree. This is necessary for supporting inline requires. I will do that in next commit. * Lazily compute Hook list on first render This ensures inline requires don't break comparisons between Hook signatures of previous and next versions by caching Hook list at the time of first render. * Refactor computing Hook signature keys Instead of a traversal during the comparison, explicitly compute full keys. This makes it easier to debug mismatches.
Garbage
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.
Before submitting a pull request, please make sure the following is done...
master
.npm test
).npm run lint
) - we've done our best to make sure these rules match our internal linting guidelines.