react/packages/shared/ReactTypes.js

255 lines
7.0 KiB
JavaScript
Raw Normal View History

2016-05-27 09:13:21 +08:00
/**
* Copyright (c) Facebook, Inc. and its affiliates.
2016-05-27 09:13:21 +08:00
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
2016-05-27 09:13:21 +08:00
*
* @flow
*/
2017-03-14 08:05:18 +08:00
export type ReactNode =
| React$Element<any>
2017-03-14 08:05:18 +08:00
| ReactPortal
| ReactText
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
| ReactFragment
| ReactProvider<any>
| ReactConsumer<any>;
export type ReactEmpty = null | void | boolean;
2016-05-27 09:13:21 +08:00
export type ReactFragment = ReactEmpty | Iterable<React$Node>;
2016-05-27 09:13:21 +08:00
export type ReactNodeList = ReactEmpty | React$Node;
2016-05-27 09:13:21 +08:00
export type ReactText = string | number;
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
export type ReactProvider<T> = {
$$typeof: Symbol | number,
type: ReactProviderType<T>,
key: null | string,
ref: null,
props: {
value: T,
children?: ReactNodeList,
...
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
},
...
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
};
export type ReactProviderType<T> = {
$$typeof: Symbol | number,
_context: ReactContext<T>,
...
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
};
export type ReactConsumer<T> = {
$$typeof: Symbol | number,
type: ReactContext<T>,
key: null | string,
ref: null,
props: {
children: (value: T) => ReactNodeList,
unstable_observedBits?: number,
...
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
},
...
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
};
export type ReactContext<T> = {
$$typeof: Symbol | number,
Consumer: ReactContext<T>,
Provider: ReactProviderType<T>,
_calculateChangedBits: ((a: T, b: T) => number) | null,
_currentValue: T,
_currentValue2: T,
Use unique thread ID for each partial render to access Context (#14182) * BUG: ReactPartialRenderer / New Context polutes mutable global state The new context API stores the provided values on the shared context instance. When used in a synchronous context, this is not an issue. However when used in an concurrent context this can cause a "push provider" from one react render to have an effect on an unrelated concurrent react render. I've encountered this bug in production when using renderToNodeStream, which asks ReactPartialRenderer for bytes up to a high water mark before yielding. If two Node Streams are created and read from in parallel, the state of one can polute the other. I wrote a failing test to illustrate the conditions under which this happens. I'm also concerned that the experimental concurrent/async React rendering on the client could suffer from the same issue. * Use unique thread ID for each partial render to access Context This first adds an allocator that keeps track of a unique ThreadID index for each currently executing partial renderer. IDs are not just growing but are reused as streams are destroyed. This ensures that IDs are kept nice and compact. This lets us use an "array" for each Context object to store the current values. The look up for these are fast because they're just looking up an offset in a tightly packed "array". I don't use an actual Array object to store the values. Instead, I rely on that VMs (notably V8) treat storage of numeric index property access as a separate "elements" allocation. This lets us avoid an extra indirection. However, we must ensure that these arrays are not holey to preserve this feature. To do that I store the _threadCount on each context (effectively it takes the place of the .length property on an array). This lets us first validate that the context has enough slots before we access the slot. If not, we fill in the slots with the default value.
2018-11-10 07:38:20 +08:00
_threadCount: number,
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
// DEV only
_currentRenderer?: Object | null,
_currentRenderer2?: Object | null,
// This value may be added by application code
// to improve DEV tooling display names
displayName?: string,
...
New context API (#11818) * New context API Introduces a declarative context API that propagates updates even when shouldComponentUpdate returns false. * Fuzz tester for context * Use ReactElement for provider and consumer children * Unify more branches in createFiberFromElement * Compare context values using Object.is Same semantics as PureComponent/shallowEqual. * Add support for Provider and Consumer to server-side renderer * Store providers on global stack Rather than using a linked list stored on the context type. The global stack can be reset in case of an interruption or error, whereas with the linked list implementation, you'd need to keep track of every context type. * Put new context API behind a feature flag We'll enable this in www only for now. * Store nearest provider on context object * Handle reentrancy in server renderer Context stack should be per server renderer instance. * Bailout of consumer updates using bitmask The context type defines an optional function that compares two context values, returning a bitfield. A consumer may specify the bits it needs for rendering. If a provider's context changes, and the consumer's bits do not intersect with the changed bits, we can skip the consumer. This is similar to how selectors are used in Redux but fast enough to do while scanning the tree. The only user code involved is the function that computes the changed bits. But that's only called once per provider update, not for every consumer. * Store current value and changed bits on context object There are fewer providers than consumers, so better to do this work at the provider. * Use maximum of 31 bits for bitmask This is the largest integer size in V8 on 32-bit systems. Warn in development if too large a number is used. * ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer * Inline Object.is * Warn if multiple renderers concurrently render the same context provider Let's see if we can get away with not supporting this for now. If it turns out that it's needed, we can fall back to backtracking the fiber return path. * Nits that came up during review
2018-01-25 11:36:22 +08:00
};
ReactNative flat renderer bundles (#9626) * Split ReactNativeFiber into separate ReactNativeFiberRenderer module Hopefully this is sufficient to work around Rollup circular dependency problems. (To be seen in subsequent commits...) * Split findNodeHandle into findNodeHandleFiber + findNodeHandleStack This allowed me to remove the ReactNative -> findNodeHandle injections, which should in turn allow me to require a fully-functional findNodeHandle without going through ReactNative. This will hopefully allow ReactNativeBaseomponent to avoid a circular dependency. * Un-forked findNodeHandle in favor of just inlining the findNode function impl * takeSnapshot no longer requires/depends-on ReactNative for findNodeHandle Instead it uses the new, renderer-specific wrappers (eg findNodeHandleFiberWrapper and findNodeHandleStackWrapper) to ensure the returned value is numeric (or null). This avoids a circular dependency that would trip up Rollup. * NativeMethodsMixin requires findNodeHandler wrapper(s) directly rather than ReactNative This works around a potential circular dependency that would break the Rollup build * Add RN_* build targets to hash-finle-name check * Strip @providesModule annotations from headers for RN_* builds * Added process.env.REACT_NATIVE_USE_FIBER to ReactNativeFeatureFlags This is kind of a hacky solution, but it is temporary. It works around the fact that ReactNativeFeatureFlag values need to be set at build time in order to avoid a mismatch between runtime flag values. DOM avoids the need to do this by using injection but Native is not able to use this same approach due to circular dependency issues. * Moved a couple of SECRET exports to dev-only. Removed SyntheticEvent and PooledClass from SECRET exports. Converted Rollup helper function to use named params. * Split NativeMethodsMixins interface and object-type * Add @noflow header to flat-bundle template to avoid triggering Flow problems When Flow tries to infer such a large file, it consumes massive amounts of CPU/RAM and can often lead to programs crashing. It is better for such large files to use .flow.js types instead. * NativeMethodsMixin and ReactNativeFiberHostComponent now share the same Flow type * Collocated (externally exposed) ReactTypes and ReactNativeTypes into single files to be synced to fbsource. ReactNativeFiber and ReactNativeStack use ReactNativeType Flow type * Build script syncs RN types and PooledClass automatically * Added optional sync-RN step to Rollup build script * Added results.json for new RN bundles
2017-05-25 00:06:30 +08:00
export type ReactPortal = {
$$typeof: Symbol | number,
key: null | string,
containerInfo: any,
children: ReactNodeList,
// TODO: figure out the API for cross-renderer implementation.
implementation: any,
...
ReactNative flat renderer bundles (#9626) * Split ReactNativeFiber into separate ReactNativeFiberRenderer module Hopefully this is sufficient to work around Rollup circular dependency problems. (To be seen in subsequent commits...) * Split findNodeHandle into findNodeHandleFiber + findNodeHandleStack This allowed me to remove the ReactNative -> findNodeHandle injections, which should in turn allow me to require a fully-functional findNodeHandle without going through ReactNative. This will hopefully allow ReactNativeBaseomponent to avoid a circular dependency. * Un-forked findNodeHandle in favor of just inlining the findNode function impl * takeSnapshot no longer requires/depends-on ReactNative for findNodeHandle Instead it uses the new, renderer-specific wrappers (eg findNodeHandleFiberWrapper and findNodeHandleStackWrapper) to ensure the returned value is numeric (or null). This avoids a circular dependency that would trip up Rollup. * NativeMethodsMixin requires findNodeHandler wrapper(s) directly rather than ReactNative This works around a potential circular dependency that would break the Rollup build * Add RN_* build targets to hash-finle-name check * Strip @providesModule annotations from headers for RN_* builds * Added process.env.REACT_NATIVE_USE_FIBER to ReactNativeFeatureFlags This is kind of a hacky solution, but it is temporary. It works around the fact that ReactNativeFeatureFlag values need to be set at build time in order to avoid a mismatch between runtime flag values. DOM avoids the need to do this by using injection but Native is not able to use this same approach due to circular dependency issues. * Moved a couple of SECRET exports to dev-only. Removed SyntheticEvent and PooledClass from SECRET exports. Converted Rollup helper function to use named params. * Split NativeMethodsMixins interface and object-type * Add @noflow header to flat-bundle template to avoid triggering Flow problems When Flow tries to infer such a large file, it consumes massive amounts of CPU/RAM and can often lead to programs crashing. It is better for such large files to use .flow.js types instead. * NativeMethodsMixin and ReactNativeFiberHostComponent now share the same Flow type * Collocated (externally exposed) ReactTypes and ReactNativeTypes into single files to be synced to fbsource. ReactNativeFiber and ReactNativeStack use ReactNativeType Flow type * Build script syncs RN types and PooledClass automatically * Added optional sync-RN step to Rollup build script * Added results.json for new RN bundles
2017-05-25 00:06:30 +08:00
};
export type RefObject = {|
current: any,
|};
export type ReactEventResponderInstance<E, C> = {|
fiber: Object,
props: Object,
responder: ReactEventResponder<E, C>,
rootEventTypes: null | Set<string>,
state: Object,
|};
export type ReactEventResponderListener<E, C> = {|
props: Object,
responder: ReactEventResponder<E, C>,
|};
export type ReactEventResponder<E, C> = {
$$typeof: Symbol | number,
displayName: string,
targetEventTypes: null | Array<string>,
targetPortalPropagation: boolean,
rootEventTypes: null | Array<string>,
getInitialState: null | ((props: Object) => Object),
onEvent:
| null
| ((event: E, context: C, props: Object, state: Object) => void),
onRootEvent:
| null
| ((event: E, context: C, props: Object, state: Object) => void),
onMount: null | ((context: C, props: Object, state: Object) => void),
onUnmount: null | ((context: C, props: Object, state: Object) => void),
...
};
export type EventPriority = 0 | 1 | 2;
export const DiscreteEvent: EventPriority = 0;
export const UserBlockingEvent: EventPriority = 1;
export const ContinuousEvent: EventPriority = 2;
export type ReactFundamentalComponentInstance<C, H> = {|
currentFiber: Object,
instance: mixed,
prevProps: null | Object,
props: Object,
impl: ReactFundamentalImpl<C, H>,
state: Object,
|};
export type ReactFundamentalImpl<C, H> = {
displayName: string,
reconcileChildren: boolean,
getInitialState?: (props: Object) => Object,
getInstance: (context: C, props: Object, state: Object) => H,
getServerSideString?: (context: C, props: Object) => string,
getServerSideStringClose?: (context: C, props: Object) => string,
onMount: (context: C, instance: mixed, props: Object, state: Object) => void,
shouldUpdate?: (
context: C,
prevProps: null | Object,
nextProps: Object,
state: Object,
) => boolean,
onUpdate?: (
context: C,
instance: mixed,
prevProps: null | Object,
nextProps: Object,
state: Object,
) => void,
onUnmount?: (
context: C,
instance: mixed,
props: Object,
state: Object,
) => void,
onHydrate?: (context: C, props: Object, state: Object) => boolean,
onFocus?: (context: C, props: Object, state: Object) => boolean,
...
};
export type ReactFundamentalComponent<C, H> = {|
$$typeof: Symbol | number,
impl: ReactFundamentalImpl<C, H>,
|};
export type ReactScope = {|
$$typeof: Symbol | number,
|};
export type ReactScopeQuery = (
type: string,
props: {[string]: mixed, ...},
instance: mixed,
) => boolean;
export type ReactScopeMethods = {|
DO_NOT_USE_queryAllNodes(ReactScopeQuery): null | Array<Object>,
DO_NOT_USE_queryFirstNode(ReactScopeQuery): null | Object,
containsNode(Object): boolean,
getChildContextValues: <T>(context: ReactContext<T>) => Array<T>,
|};
export type ReactScopeInstance = {|
fiber: Object,
methods: null | ReactScopeMethods,
|};
// Mutable source version can be anything (e.g. number, string, immutable data structure)
// so long as it changes every time any part of the source changes.
export type MutableSourceVersion = $NonMaybeType<mixed>;
export type MutableSourceGetSnapshotFn<
Source: $NonMaybeType<mixed>,
Snapshot,
> = (source: Source) => Snapshot;
export type MutableSourceSubscribeFn<Source: $NonMaybeType<mixed>, Snapshot> = (
source: Source,
callback: (snapshot: Snapshot) => void,
) => () => void;
export type MutableSourceGetVersionFn = (
source: $NonMaybeType<mixed>,
) => MutableSourceVersion;
export type MutableSource<Source: $NonMaybeType<mixed>> = {|
_source: Source,
_getVersion: MutableSourceGetVersionFn,
// Tracks the version of this source at the time it was most recently read.
// Used to determine if a source is safe to read from before it has been subscribed to.
// Version number is only used during mount,
// since the mechanism for determining safety after subscription is expiration time.
//
// As a workaround to support multiple concurrent renderers,
// we categorize some renderers as primary and others as secondary.
// We only expect there to be two concurrent renderers at most:
// React Native (primary) and Fabric (secondary);
// React DOM (primary) and React ART (secondary).
// Secondary renderers store their context values on separate fields.
// We use the same approach for Context.
_workInProgressVersionPrimary: null | MutableSourceVersion,
_workInProgressVersionSecondary: null | MutableSourceVersion,
// DEV only
// Used to detect multiple renderers using the same mutable source.
_currentPrimaryRenderer?: Object | null,
_currentSecondaryRenderer?: Object | null,
|};
// The subset of a Thenable required by things thrown by Suspense.
// This doesn't require a value to be passed to either handler.
export interface Wakeable {
then(onFulfill: () => mixed, onReject: () => mixed): void | Wakeable;
// Special flag to opt out of tracing interactions across a Suspense boundary.
__reactDoNotTraceInteractions?: boolean;
}
// The subset of a Promise that React APIs rely on. This resolves a value.
// This doesn't require a return value neither from the handler nor the
// then function.
export interface Thenable<+R> {
then<U>(
onFulfill: (value: R) => void | Thenable<U> | U,
onReject: (error: mixed) => void | Thenable<U> | U,
): void | Thenable<U>;
}