* Move findNodeHandle into the renderers and use instantiation
This is just like ReactDOM does it. This also lets us get rid of injection
for findNodeHandle. Instead I move NativeMethodsMixin and ReactNativeComponent
to use instantiation.
* Refactor findHostInstance
The reconciler shouldn't expose the Fiber data structure. We should pass
the component instance to the reconciler, since the reconciler is the
thing that is supposed to be instancemap aware.
* Fix devtools injection
* 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
* 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
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)
```
Using `new Map(iterable)` isn't supported in IE11, so it ends up trying to iterate through an empty map and these attributes don't get defined in properties. Since this is only run once on startup inlining the attributeName array is probably fine.
* Add stack unwinding phase for handling errors
A rewrite of error handling, with semantics that more closely match
stack unwinding.
Errors that are thrown during the render phase unwind to the nearest
error boundary, like before. But rather than synchronously unmount the
children before retrying, we restart the failed subtree within the same
render phase. The failed children are still unmounted (as if all their
keys changed) but without an extra commit.
Commit phase errors are different. They work by scheduling an error on
the update queue of the error boundary. When we enter the render phase,
the error is popped off the queue. The rest of the algorithm is
the same.
This approach is designed to work for throwing non-errors, too, though
that feature is not implemented yet.
* Add experimental getDerivedStateFromCatch lifecycle
Fires during the render phase, so you can recover from an error within the same
pass. This aligns error boundaries more closely with try-catch semantics.
Let's keep this behind a feature flag until a future release. For now, the
recommendation is to keep using componentDidCatch. Eventually, the advice will
be to use getDerivedStateFromCatch for handling errors and componentDidCatch
only for logging.
* Reconcile twice to remount failed children, instead of using a boolean
* Handle effect immediately after its thrown
This way we don't have to store the thrown values on the effect list.
* ReactFiberIncompleteWork -> ReactFiberUnwindWork
* Remove startTime
* Remove TypeOfException
We don't need it yet. We'll reconsider once we add another exception type.
* Move replay to outer catch block
This moves it out of the hot path.
* Add test exercising public API to test BeforeInputEventPlugin + FallbackCompositionState
- I've adopted a similar approach to the existing test for BeforeInputEventPlugin
- I've simulated events and then assert the event handler for onBeforeInput is fired or not fired based on the test conditions
- The scenarios are tested against IE11, Webkite and Presto environment simulations
- I've encorporated what I understand to be the functionality in the FallbackCompositionState test
* Prettier
* Linting fixes
* Remove test for contenteditable in Presto - the contenteditable type is not supported in Presto powered browsers (Opera).
* Remove mention of Presto as this explicit condition is no longer handled in BeforeInputEventPlugin.
We still need to exercise usage of FallbackCompositionState though so let's keep a test where the env does not support Composition and Text events.
* Add tests for envs with only CompositionEvent support
* Remove internal tests no longer needed
* Shorten test case names to satisfy lint rules
* Add tests for onCompositionStart and onCompositionUpdte events
The BeforeInputEventPlugin is responsible for emitting these events so we need to add tests for this. This also ensure we exercise the code path that, L207, that was not previously exercised with the public tests.
When a ref is removed from a class component, React now calls the previous ref-setter (if there was one) with null. Previously this was the case only for host component refs.
A new test has been added.
* add failed tests for <unstable_AsyncMode> with server rendering
* Fix server render with <unstable_AsyncMode> component
* Merge StrictMode and AsyncMode tests into Modes file
* Invoke both legacy and UNSAFE_ lifecycles when both are present
This is to support edge cases with eg create-react-class where a mixin defines a legacy lifecycle but the component being created defines an UNSAFE one (or vice versa).
I did not warn about this case because the warning would be a bit redundant with the deprecation warning which we will soon be enabling. I could be convinced to change my stance here though.
* Added explicit function-type check to SS ReactPartialRenderer
Accounts for the case where an event is dispatched synchronously from
inside another event, like `el.focus`. I've added a test, but in general
we need more coverage around this area.
* Switch to JSX API for context
80% sure this will be the final API. Merging this now so we can get this
into the next www sync in preparation for 16.3.
* Promote context to a stable API
* Updates inside controlled events (onChange) are sync even in async mode
This guarantees the DOM is in a consistent state before we yield back
to the browser.
We'll need to figure out a separate strategy for other
interactive events.
* Don't rely on flushing behavior of public batchedUpdates implementation
Flush work as an explicit step at the end of the event, right before
restoring controlled state.
* Interactive updates
At the beginning of an interactive browser event (events that fire as
the result of a user interaction, like a click), check for pending
updates that were scheduled in a previous interactive event. Flush the
pending updates synchronously so that the event handlers are up-to-date
before responding to the current event.
We now have three classes of events:
- Controlled events. Updates are always flushed synchronously.
- Interactive events. Updates are async, unless another a subsequent
event is fired before it can complete, as described above. They are
also slightly higher priority than a normal async update.
- Non-interactive events. These are treated as normal, low-priority
async updates.
* Flush lowest pending interactive update time
Accounts for case when multiple interactive updates are scheduled at
different priorities. This can happen when an interactive event is
dispatched inside an async subtree, and there's an event handler on
an ancestor that is outside the subtree.
* Update comment about restoring controlled components
* ReactDOM.flushControlled
New API for wrapping event handlers that need to fire before React
yields to the browser. Previously we thought that flushSync was
sufficient for this use case, but it turns out that flushSync is only
safe if you're guaranteed to be at the top of the stack; that is, if
you know for sure that your event handler is not nested inside another
React event handler or lifecycle. This isn't true for cases like
el.focus, el.click, or dispatchEvent, where an event handler can be
invoked synchronously from inside an existing stack.
flushControlled has similar semantics to batchedUpdates, where if you
nest multiple batches, the work is not flushed until the end of the
outermost batch. The work is not guaranteed to synchronously flush, as
with flushSync, but it is guaranteed to flush before React yields to
the browser.
flushSync is still the preferred API in most cases, such as inside
a requestAnimationFrame callback.
* Test that flushControlled does not flush inside batchedUpdates
* Make flushControlled a void function
In the future, we may want to return a thenable work object. For now,
we'll return nothing.
* flushControlled -> unstable_flushControlled
* Replace unstable_AsyncComponent with Unstable_AsyncMode
Mirrors the StrictMode API and uses the new Mode type of work.
* internalContextTag -> mode
Change this now that we have a better name
* Unstable_ -> unstable_
* Suppress unsafe/deprecation warnings for polyfilled components.
* Don't invoke deprecated lifecycles if static gDSFP exists.
* Applied recent changes to server rendering also
Builds on top of PR #12083 and resolves issue #12044.
Coalesces deprecation warnings until the commit phase. This proposal extends the utility introduced in #12060 to also coalesce deprecation warnings.
New warning format will look like this:
> componentWillMount is deprecated and will be removed in the next major version. Use componentDidMount instead. As a temporary workaround, you can rename to UNSAFE_componentWillMount.
>
> Please update the following components: Foo, Bar
>
> Learn more about this warning here:
> https://fb.me/react-async-component-lifecycle-hooks