Based on a bug found in UFI2.
There have been several bugs related to the update queue (and
specifically baseState) recently, so I'm going to follow-up with some
refactoring to clean it up. This is a quick fix so we can ship a
patch release.
* Add regression tests for error boundary replay bugs
* Ensure the context stack is aligned if renderer throws
* Always throw when replaying a failed unit of work
Replaying a failed unit of work should always throw, because the render
phase is meant to be idempotent, If it doesn't throw, rethrow the
original error, so React's internal stack is not misaligned.
* Reset originalReplayError after replaying
* Typo fix
* Update user timing to record when we are about to commit
**what is the change?:**
After repeatedly logging '(React Tree Reconciliation)' we vary the
message slightly for the last reconciliation, which happens right before
we commit.
**why make this change?:**
When debugging performance in the devtools it will be helpful if we can
quickly see where the 'commit' happens in a potentially long list of
sliced '(React Tree Reconciliation)' logs.
**test plan:**
Built and ran one of the fixtures. Also ran the unit test.
(Flarnie will insert a screenshot)
* Ran prettier
* Fixes in response to code review
* Update snapshot tests
* Move isWorking assignment out of branches to top
* Stricter type for stopWorkLoopTimer args
* Fix DEV performance regression by avoiding Object.assign on Fibers
* Reduce allocations in hot path by reusing the stash
Since performUnitOfWork() is not reentrant, it should be safe to reuse the same stash every time instead of creating a new object.
* Add React.isValidElementType()
Per the conversation on #12453, there are a number of third-party
libraries (particularly those that generate higher-order components)
that are performing suboptimal validation of element types.
This commit exposes a function that can perform the desired check
without depending upon React internals.
* Move isValidElementType to shared/
* Update user timing to record the timeout deadline with 'waiting' events
**what is the change?:**
When we are processing work during reconciliation, we have a "timeout"
deadline to finish the work. It's a safety measure that forces things to
finish up synchronously if they are taking too long.
The "timeout" is different depending on the type of interaction which
triggered the reconciliation. We currently have a shorter "timeout" for
"interactive updates", meaning we will try to finish work faster if the
reconciliation was triggered by a click or other user interaction.
For collecting more data in our logs we want to differentiate the
'waiting for async callback...' events based on the "timeout" so I'm
adding that to the logging.
One interesting note - in one of the snapshot tests the "timeout" was
super high. Going to look into that.
**why make this change?:**
Right now we are debugging cases where an interaction triggers a
reconciliation and the "waiting for async callback...' events are too
long, getting blocked because the main thread is too busy. We are
keeping logs of these user timing events and want to filter to focus on
the reconciliation triggered by interaction.
**test plan:**
Manually tested and also updated snapshot tests.
(Flarnie will insert a screenshot)
* Improve wording of message
* ran prettier
* Test case for React Context bailing out unexpectedly
* This is 💯% definitely not the correct fix at all
* Revert "This is 💯% definitely not the correct fix at all"
This reverts commit 8686c0f6bdc1cba3056fb2212f3f7740c749d33a.
* Formatting + minor tweaks to the test
* Don't bail out on consumer child equality
* Tweak the comment
* Pretty lint
* Silly Dan
* Add a failing test for setState in cDM during batch.commit()
* Copy pasta
* Flush all follow-up Sync work on the committed batch
* Nit: Use performSyncWork
Call performSyncWork right after flushing the batch. Does effectively
the same thing by reusing the existing function.
Also added some comments.
* Delete accidentally duplicated test
These are based on the ReactNoop renderer, which we use to test React
itself. This gives library authors (Relay, Apollo, Redux, et al.) a way
to test their components for async compatibility.
- Pass `unstable_isAsync` to `TestRenderer.create` to create an async
renderer instance. This causes updates to be lazily flushed.
- `renderer.unstable_yield` tells React to yield execution after the
currently rendering component.
- `renderer.unstable_flushAll` flushes all pending async work, and
returns an array of yielded values.
- `renderer.unstable_flushThrough` receives an array of expected values,
begins rendering, and stops once those values have been yielded. It
returns the array of values that are actually yielded. The user should
assert that they are equal.
Although we've used this pattern successfully in our own tests, I'm not
sure if these are the final APIs we'll make public.
* Call getSnapshotBeforeUpdate in separate traversal, before mutation (aka revert db84b9a) and add unit test.
* Added a new timer to ReactDebugFiberPerf for Snapshot effects
* Implemented new getSnapshotBeforeUpdate lifecycle
* Store snapshot value from Fiber to instance (__reactInternalSnapshotBeforeUpdate)
* Use commitAllHostEffects() traversal for getSnapshotBeforeUpdate()
* Added DEV warnings and tests for new lifecycle
* Don't invoke legacy lifecycles if getSnapshotBeforeUpdate() is defined. DEV warn about this.
* Converted did-warn objects to Sets in ReactFiberClassComponent
* Replaced redundant new lifecycle checks in a few methods
* Check for polyfill suppress flag on cWU as well before warning
* Added Snapshot bit to HostEffectMask
Is this necessary? I'd like to use the package in enzyme to avoid having to recopy/paste the symbols for better debugging names, but at hard dep in enzyme proper on a version of react isn't gonna work. This seems safe since nothing explicitly depends on React in here?
