2018-02-06 00:56:21 +08:00
|
|
|
/**
|
|
|
|
|
* Copyright (c) 2013-present, Facebook, Inc.
|
|
|
|
|
*
|
|
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
|
|
|
|
*
|
|
|
|
|
* @flow
|
|
|
|
|
*/
|
|
|
|
|
|
2018-06-19 23:03:45 +08:00
|
|
|
import invariant from 'shared/invariant';
|
2018-02-06 00:56:21 +08:00
|
|
|
|
|
|
|
|
import typeof * as FeatureFlagsType from 'shared/ReactFeatureFlags';
|
|
|
|
|
import typeof * as PersistentFeatureFlagsType from './ReactFeatureFlags.persistent';
|
|
|
|
|
|
|
|
|
|
export const debugRenderPhaseSideEffects = false;
|
|
|
|
|
export const debugRenderPhaseSideEffectsForStrictMode = false;
|
|
|
|
|
export const enableUserTimingAPI = __DEV__;
|
Add stack unwinding phase for handling errors (#12201)
* 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.
2018-02-24 09:38:42 +08:00
|
|
|
export const enableGetDerivedStateFromCatch = false;
|
Suspense (#12279)
* Timeout component
Adds Timeout component. If a promise is thrown from inside a Timeout component,
React will suspend the in-progress render from committing. When the promise
resolves, React will retry. If the render is suspended for longer than the
maximum threshold, the Timeout switches to a placeholder state.
The timeout threshold is defined as the minimum of:
- The expiration time of the current render
- The `ms` prop given to each Timeout component in the ancestor path of the
thrown promise.
* Add a test for nested fallbacks
Co-authored-by: Andrew Clark <acdlite@fb.com>
* Resume on promise rejection
React should resume rendering regardless of whether it resolves
or rejects.
* Wrap Suspense code in feature flag
* Children of a Timeout must be strict mode compatible
Async is not required for Suspense, but strict mode is.
* Simplify list of pending work
Some of this was added with "soft expiration" in mind, but now with our revised
model for how soft expiration will work, this isn't necessary.
It would be nice to remove more of this, but I think the list itself is inherent
because we need a way to track the start times, for <Timeout ms={ms} />.
* Only use the Timeout update queue to store promises, not for state
It already worked this way in practice.
* Wrap more Suspense-only paths in the feature flag
* Attach promise listener immediately on suspend
Instead of waiting for commit phase.
* Infer approximate start time using expiration time
* Remove list of pending priority levels
We can replicate almost all the functionality by tracking just five
separate levels: the highest/lowest priority pending levels, the
highest/lowest priority suspended levels, and the lowest pinged level.
We lose a bit of granularity, in that if there are multiple levels of
pending updates, only the first and last ones are known. But in practice
this likely isn't a big deal.
These heuristics are almost entirely isolated to a single module and
can be adjusted later, without API changes, if necessary.
Non-IO-bound work is not affected at all.
* ReactFiberPendingWork -> ReactFiberPendingPriority
* Renaming method names from "pending work" to "pending priority"
* Get rid of SuspenseThenable module
Idk why I thought this was neccessary
* Nits based on Sebastian's feedback
* More naming nits + comments
* Add test for hiding a suspended tree to unblock
* Revert change to expiration time rounding
This means you have to account for the start time approximation
heuristic when writing Suspense tests, but that's going to be
true regardless.
When updating the tests, I also made a fix related to offscreen
priority. We should never timeout inside a hidden tree.
* palceholder -> placeholder
2018-05-11 09:09:10 +08:00
|
|
|
export const enableSuspense = false;
|
2018-02-06 00:56:21 +08:00
|
|
|
export const warnAboutDeprecatedLifecycles = false;
|
2018-05-23 06:38:02 +08:00
|
|
|
export const warnAboutLegacyContextAPI = false;
|
Add stack unwinding phase for handling errors (#12201)
* 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.
2018-02-24 09:38:42 +08:00
|
|
|
export const replayFailedUnitOfWorkWithInvokeGuardedCallback = __DEV__;
|
2018-06-27 04:28:41 +08:00
|
|
|
export const enableProfilerTimer = __PROFILE__;
|
2018-09-02 03:00:00 +08:00
|
|
|
export const enableSchedulerTracking = __PROFILE__;
|
2018-09-06 06:04:59 +08:00
|
|
|
export const enableSuspenseServerRenderer = false;
|
2018-02-06 00:56:21 +08:00
|
|
|
|
|
|
|
|
// Only used in www builds.
|
|
|
|
|
export function addUserTimingListener() {
|
|
|
|
|
invariant(false, 'Not implemented.');
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Flow magic to verify the exports of this file match the original version.
|
|
|
|
|
// eslint-disable-next-line no-unused-vars
|
|
|
|
|
type Check<_X, Y: _X, X: Y = _X> = null;
|
|
|
|
|
// eslint-disable-next-line no-unused-expressions
|
|
|
|
|
(null: Check<PersistentFeatureFlagsType, FeatureFlagsType>);
|