* 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?
* Add a failing test verifying componentInfo is missing
* Pass componentInfo to componentDidCatch and getDerivedStateFromCatch
* Only expect stack in DEV
* Don't pass the stack to getDerivedStateFromCatch()
FiberNode stateNode could be null
So I get TypeError:
```
at performWorkOnRoot (/tmp/my-project/node_modules/react-dom/cjs/react-dom.development.js:11014:24) TypeError: Cannot read property '_warnedAboutRefsInRender' of null
at findDOMNode (/tmp/my-project/node_modules/react-dom/cjs/react-dom.development.js:15264:55)
```
* Add a regression test for the context infinite loop
* Fix the bug
We set .return pointer inside the loop, but the top-level parent-child relationship happens outside.
This ensures the top-level parent's child points to the right copy of the parent.
Otherwise we may end up in a situation where (workInProgress === nextFiber) is never true and we loop forever.
* Support ForwardRef type of work in TestRenderer and ShallowRenderer.
* Release script now updates inter-package dependencies too (e.g. react-test-renderer depends on react-is).
We'll use this in www to test whether the polyfill is better at
scheduling high-pri async work than the native one. My preliminary tests
suggest "yes" but it's hard to say for certain, given how difficult it
is to consistently reproduce the starvation issues we've been seeing.
* Use module pattern so context stack is isolated per renderer
* Unify context implementations
Implements the new context API on top of the existing ReactStack that we
already use for host context and legacy context. Now there is a single
array that we push and pop from.
This makes the interrupt path slightly slower, since when we reset the
unit of work pointer, we have to iterate over the stack (like before)
*and* switch on the type of work (not like before). On the other hand,
this unifies all of the unwinding behavior in the UnwindWork module.
* Add DEV only warning if stack is not reset properly
Brian Vaughn