2016-10-30 00:43:34 +01:00
|
|
|
/**
|
2022-10-18 11:19:24 -04:00
|
|
|
* Copyright (c) Meta Platforms, Inc. and affiliates.
|
2016-10-30 00:43:34 +01:00
|
|
|
*
|
2017-09-24 13:48:13 -07:00
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
2016-10-30 00:43:34 +01:00
|
|
|
*
|
2017-04-05 16:47:29 +01:00
|
|
|
* @flow
|
2016-10-30 00:43:34 +01:00
|
|
|
*/
|
|
|
|
|
|
2020-03-04 20:52:48 -08:00
|
|
|
import type {LazyComponent} from 'react/src/ReactLazy';
|
2024-02-13 15:04:49 +00:00
|
|
|
import type {ReactContext, ReactConsumerType} from 'shared/ReactTypes';
|
Accept promise as element type (#13397)
* Accept promise as element type
On the initial render, the element will suspend as if a promise were
thrown from inside the body of the unresolved component. Siblings should
continue rendering and if the parent is a Placeholder, the promise
should be captured by that Placeholder.
When the promise resolves, rendering resumes. If the resolved value
has a `default` property, it is assumed to be the default export of
an ES module, and we use that as the component type. If it does not have
a `default` property, we use the resolved value itself.
The resolved value is stored as an expando on the promise/thenable.
* Use special types of work for lazy components
Because reconciliation is a hot path, this adds ClassComponentLazy,
FunctionalComponentLazy, and ForwardRefLazy as special types of work.
The other types are not supported, but wouldn't be placed into a
separate module regardless.
* Resolve defaultProps for lazy types
* Remove some calls to isContextProvider
isContextProvider checks the fiber tag, but it's typically called after
we've already refined the type of work. We should get rid of it. I
removed some of them in the previous commit, and deleted a few more
in this one. I left a few behind because the remaining ones would
require additional refactoring that feels outside the scope of this PR.
* Remove getLazyComponentTypeIfResolved
* Return baseProps instead of null
The caller compares the result to baseProps to see if anything changed.
* Avoid redundant checks by inlining getFiberTagFromObjectType
* Move tag resolution to ReactFiber module
* Pass next props to update* functions
We should do this with all types of work in the future.
* Refine component type before pushing/popping context
Removes unnecessary checks.
* Replace all occurrences of _reactResult with helper
* Move shared thenable logic to `shared` package
* Check type of wrapper object before resolving to `default` export
* Return resolved tag instead of reassigning
2018-08-16 09:21:59 -07:00
|
|
|
|
2017-12-12 15:04:40 -08:00
|
|
|
import {
|
2018-05-14 10:10:36 -07:00
|
|
|
REACT_CONTEXT_TYPE,
|
2024-02-13 15:04:49 +00:00
|
|
|
REACT_CONSUMER_TYPE,
|
2018-05-10 15:25:32 -07:00
|
|
|
REACT_FORWARD_REF_TYPE,
|
2017-12-12 15:04:40 -08:00
|
|
|
REACT_FRAGMENT_TYPE,
|
|
|
|
|
REACT_PORTAL_TYPE,
|
2018-10-20 12:46:23 -04:00
|
|
|
REACT_MEMO_TYPE,
|
2018-05-10 15:25:32 -07:00
|
|
|
REACT_PROFILER_TYPE,
|
|
|
|
|
REACT_STRICT_MODE_TYPE,
|
2018-10-10 17:02:04 +01:00
|
|
|
REACT_SUSPENSE_TYPE,
|
2019-06-19 19:34:28 -07:00
|
|
|
REACT_SUSPENSE_LIST_TYPE,
|
2018-10-18 19:57:12 -07:00
|
|
|
REACT_LAZY_TYPE,
|
2022-02-11 11:42:55 -05:00
|
|
|
REACT_TRACING_MARKER_TYPE,
|
Add <ViewTransition> Component (#31975)
This will provide the opt-in for using [View
Transitions](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API)
in React.
View Transitions only trigger for async updates like `startTransition`,
`useDeferredValue`, Actions or `<Suspense>` revealing from fallback to
content. Synchronous updates provide an opt-out but also guarantee that
they commit immediately which View Transitions can't.
There's no need to opt-in to View Transitions at the "cause" side like
event handlers or actions. They don't know what UI will change and
whether that has an animated transition described.
Conceptually the `<ViewTransition>` component is like a DOM fragment
that transitions its children in its own isolate/snapshot. The API works
by wrapping a DOM node or inner component:
```js
import {ViewTransition} from 'react';
<ViewTransition><Component /></ViewTransition>
```
The default is `name="auto"` which will automatically assign a
`view-transition-name` to the inner DOM node. That way you can add a
View Transition to a Component without controlling its DOM nodes styling
otherwise.
A difference between this and the browser's built-in
`view-transition-name: auto` is that switching the DOM nodes within the
`<ViewTransition>` component preserves the same name so this example
cross-fades between the DOM nodes instead of causing an exit and enter:
```js
<ViewTransition>{condition ? <ComponentA /> : <ComponentB />}</ViewTransition>
```
This becomes especially useful with `<Suspense>` as this example
cross-fades between Skeleton and Content:
```js
<ViewTransition>
<Suspense fallback={<Skeleton />}>
<Content />
</Suspense>
</ViewTransition>
```
Where as this example triggers an exit of the Skeleton and an enter of
the Content:
```js
<Suspense fallback={<ViewTransition><Skeleton /></ViewTransition>}>
<ViewTransition><Content /></ViewTransition>
</Suspense>
```
Managing instances and keys becomes extra important.
You can also specify an explicit `name` property for example for
animating the same conceptual item from one page onto another. However,
best practices is to property namespace these since they can easily
collide. It's also useful to add an `id` to it if available.
```js
<ViewTransition name="my-shared-view">
```
The model in general is the same as plain `view-transition-name` except
React manages a set of heuristics for when to apply it. A problem with
the naive View Transitions model is that it overly opts in every
boundary that *might* transition into transitioning. This is leads to
unfortunate effects like things floating around when unrelated updates
happen. This leads the whole document to animate which means that
nothing is clickable in the meantime. It makes it not useful for smaller
and more local transitions. Best practice is to add
`view-transition-name` only right before you're about to need to animate
the thing. This is tricky to manage globally on complex apps and is not
compositional. Instead we let React manage when a `<ViewTransition>`
"activates" and add/remove the `view-transition-name`. This is also when
React calls `startViewTransition` behind the scenes while it mutates the
DOM.
I've come up with a number of heuristics that I think will make a lot
easier to coordinate this. The principle is that only if something that
updates that particular boundary do we activate it. I hope that one day
maybe browsers will have something like these built-in and we can remove
our implementation.
A `<ViewTransition>` only activates if:
- If a mounted Component renders a `<ViewTransition>` within it outside
the first DOM node, and it is within the viewport, then that
ViewTransition activates as an "enter" animation. This avoids inner
"enter" animations trigger when the parent mounts.
- If an unmounted Component had a `<ViewTransition>` within it outside
the first DOM node, and it was within the viewport, then that
ViewTransition activates as an "exit" animation. This avoids inner
"exit" animations triggering when the parent unmounts.
- If an explicitly named `<ViewTransition name="...">` is deep within an
unmounted tree and one with the same name appears in a mounted tree at
the same time, then both are activated as a pair, but only if they're
both in the viewport. This avoids these triggering "enter" or "exit"
animations when going between parents that don't have a pair.
- If an already mounted `<ViewTransition>` is visible and a DOM
mutation, that might affect how it's painted, happens within its
children but outside any nested `<ViewTransition>`. This allows it to
"cross-fade" between its updates.
- If an already mounted `<ViewTransition>` resizes or moves as the
result of direct DOM nodes siblings changing or moving around. This
allows insertion, deletion and reorders into a list to animate all
children. It is only within one DOM node though, to avoid unrelated
changes in the parent to trigger this. If an item is outside the
viewport before and after, then it's skipped to avoid things flying
across the screen.
- If a `<ViewTransition>` boundary changes size, due to a DOM mutation
within it, then the parent activates (or the root document if there are
no more parents). This ensures that the container can cross-fade to
avoid abrupt relayout. This can be avoided by using absolutely
positioned children. When this can avoid bubbling to the root document,
whatever is not animating is still responsive to clicks during the
transition.
Conceptually each DOM node has its own default that activates the parent
`<ViewTransition>` or no transition if the parent is the root. That
means that if you add a DOM node like `<div><ViewTransition><Component
/></ViewTransition></div>` this won't trigger an "enter" animation since
it was the div that was added, not the ViewTransition. Instead, it might
cause a cross-fade of the parent ViewTransition or no transition if it
had no parent. This ensures that only explicit boundaries perform coarse
animations instead of every single node which is really the benefit of
the View Transitions model. This ends up working out well for simple
cases like switching between two pages immediately while transitioning
one floating item that appears on both pages. Because only the floating
item transitions by default.
Note that it's possible to add manual `view-transition-name` with CSS or
`style={{ viewTransitionName: 'auto' }}` that always transitions as long
as something else has a `<ViewTransition>` that activates. For example a
`<ViewTransition>` can wrap a whole page for a cross-fade but inside of
it an explicit name can be added to something to ensure it animates as a
move when something relates else changes its layout. Instead of just
cross-fading it along with the Page which would be the default.
There's more PRs coming with some optimizations, fixes and expanded
APIs. This first PR explores the above core heuristic.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <silbermann.sebastian@gmail.com>
2025-01-08 12:11:18 -05:00
|
|
|
REACT_VIEW_TRANSITION_TYPE,
|
2025-03-17 09:17:00 -04:00
|
|
|
REACT_ACTIVITY_TYPE,
|
2017-12-12 15:04:40 -08:00
|
|
|
} from 'shared/ReactSymbols';
|
|
|
|
|
|
2024-02-13 15:04:49 +00:00
|
|
|
import {
|
|
|
|
|
enableTransitionTracing,
|
Add <ViewTransition> Component (#31975)
This will provide the opt-in for using [View
Transitions](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API)
in React.
View Transitions only trigger for async updates like `startTransition`,
`useDeferredValue`, Actions or `<Suspense>` revealing from fallback to
content. Synchronous updates provide an opt-out but also guarantee that
they commit immediately which View Transitions can't.
There's no need to opt-in to View Transitions at the "cause" side like
event handlers or actions. They don't know what UI will change and
whether that has an animated transition described.
Conceptually the `<ViewTransition>` component is like a DOM fragment
that transitions its children in its own isolate/snapshot. The API works
by wrapping a DOM node or inner component:
```js
import {ViewTransition} from 'react';
<ViewTransition><Component /></ViewTransition>
```
The default is `name="auto"` which will automatically assign a
`view-transition-name` to the inner DOM node. That way you can add a
View Transition to a Component without controlling its DOM nodes styling
otherwise.
A difference between this and the browser's built-in
`view-transition-name: auto` is that switching the DOM nodes within the
`<ViewTransition>` component preserves the same name so this example
cross-fades between the DOM nodes instead of causing an exit and enter:
```js
<ViewTransition>{condition ? <ComponentA /> : <ComponentB />}</ViewTransition>
```
This becomes especially useful with `<Suspense>` as this example
cross-fades between Skeleton and Content:
```js
<ViewTransition>
<Suspense fallback={<Skeleton />}>
<Content />
</Suspense>
</ViewTransition>
```
Where as this example triggers an exit of the Skeleton and an enter of
the Content:
```js
<Suspense fallback={<ViewTransition><Skeleton /></ViewTransition>}>
<ViewTransition><Content /></ViewTransition>
</Suspense>
```
Managing instances and keys becomes extra important.
You can also specify an explicit `name` property for example for
animating the same conceptual item from one page onto another. However,
best practices is to property namespace these since they can easily
collide. It's also useful to add an `id` to it if available.
```js
<ViewTransition name="my-shared-view">
```
The model in general is the same as plain `view-transition-name` except
React manages a set of heuristics for when to apply it. A problem with
the naive View Transitions model is that it overly opts in every
boundary that *might* transition into transitioning. This is leads to
unfortunate effects like things floating around when unrelated updates
happen. This leads the whole document to animate which means that
nothing is clickable in the meantime. It makes it not useful for smaller
and more local transitions. Best practice is to add
`view-transition-name` only right before you're about to need to animate
the thing. This is tricky to manage globally on complex apps and is not
compositional. Instead we let React manage when a `<ViewTransition>`
"activates" and add/remove the `view-transition-name`. This is also when
React calls `startViewTransition` behind the scenes while it mutates the
DOM.
I've come up with a number of heuristics that I think will make a lot
easier to coordinate this. The principle is that only if something that
updates that particular boundary do we activate it. I hope that one day
maybe browsers will have something like these built-in and we can remove
our implementation.
A `<ViewTransition>` only activates if:
- If a mounted Component renders a `<ViewTransition>` within it outside
the first DOM node, and it is within the viewport, then that
ViewTransition activates as an "enter" animation. This avoids inner
"enter" animations trigger when the parent mounts.
- If an unmounted Component had a `<ViewTransition>` within it outside
the first DOM node, and it was within the viewport, then that
ViewTransition activates as an "exit" animation. This avoids inner
"exit" animations triggering when the parent unmounts.
- If an explicitly named `<ViewTransition name="...">` is deep within an
unmounted tree and one with the same name appears in a mounted tree at
the same time, then both are activated as a pair, but only if they're
both in the viewport. This avoids these triggering "enter" or "exit"
animations when going between parents that don't have a pair.
- If an already mounted `<ViewTransition>` is visible and a DOM
mutation, that might affect how it's painted, happens within its
children but outside any nested `<ViewTransition>`. This allows it to
"cross-fade" between its updates.
- If an already mounted `<ViewTransition>` resizes or moves as the
result of direct DOM nodes siblings changing or moving around. This
allows insertion, deletion and reorders into a list to animate all
children. It is only within one DOM node though, to avoid unrelated
changes in the parent to trigger this. If an item is outside the
viewport before and after, then it's skipped to avoid things flying
across the screen.
- If a `<ViewTransition>` boundary changes size, due to a DOM mutation
within it, then the parent activates (or the root document if there are
no more parents). This ensures that the container can cross-fade to
avoid abrupt relayout. This can be avoided by using absolutely
positioned children. When this can avoid bubbling to the root document,
whatever is not animating is still responsive to clicks during the
transition.
Conceptually each DOM node has its own default that activates the parent
`<ViewTransition>` or no transition if the parent is the root. That
means that if you add a DOM node like `<div><ViewTransition><Component
/></ViewTransition></div>` this won't trigger an "enter" animation since
it was the div that was added, not the ViewTransition. Instead, it might
cause a cross-fade of the parent ViewTransition or no transition if it
had no parent. This ensures that only explicit boundaries perform coarse
animations instead of every single node which is really the benefit of
the View Transitions model. This ends up working out well for simple
cases like switching between two pages immediately while transitioning
one floating item that appears on both pages. Because only the floating
item transitions by default.
Note that it's possible to add manual `view-transition-name` with CSS or
`style={{ viewTransitionName: 'auto' }}` that always transitions as long
as something else has a `<ViewTransition>` that activates. For example a
`<ViewTransition>` can wrap a whole page for a cross-fade but inside of
it an explicit name can be added to something to ensure it animates as a
move when something relates else changes its layout. Instead of just
cross-fading it along with the Page which would be the default.
There's more PRs coming with some optimizations, fixes and expanded
APIs. This first PR explores the above core heuristic.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <silbermann.sebastian@gmail.com>
2025-01-08 12:11:18 -05:00
|
|
|
enableViewTransition,
|
2024-02-13 15:04:49 +00:00
|
|
|
} from './ReactFeatureFlags';
|
2022-03-07 21:13:22 -08:00
|
|
|
|
2021-03-05 16:02:02 -05:00
|
|
|
// Keep in sync with react-reconciler/getComponentNameFromFiber
|
2018-10-12 03:15:14 +01:00
|
|
|
function getWrappedName(
|
|
|
|
|
outerType: mixed,
|
|
|
|
|
innerType: any,
|
|
|
|
|
wrapperName: string,
|
|
|
|
|
): string {
|
2021-05-04 11:40:16 -04:00
|
|
|
const displayName = (outerType: any).displayName;
|
|
|
|
|
if (displayName) {
|
|
|
|
|
return displayName;
|
|
|
|
|
}
|
2018-10-12 03:15:14 +01:00
|
|
|
const functionName = innerType.displayName || innerType.name || '';
|
2021-05-04 11:40:16 -04:00
|
|
|
return functionName !== '' ? `${wrapperName}(${functionName})` : wrapperName;
|
2018-10-12 03:15:14 +01:00
|
|
|
}
|
|
|
|
|
|
2021-03-05 16:02:02 -05:00
|
|
|
// Keep in sync with react-reconciler/getComponentNameFromFiber
|
2020-03-05 10:13:52 -08:00
|
|
|
function getContextName(type: ReactContext<any>) {
|
|
|
|
|
return type.displayName || 'Context';
|
|
|
|
|
}
|
|
|
|
|
|
2024-01-11 17:24:26 -05:00
|
|
|
const REACT_CLIENT_REFERENCE = Symbol.for('react.client.reference');
|
|
|
|
|
|
2021-03-05 16:02:02 -05:00
|
|
|
// Note that the reconciler package should generally prefer to use getComponentNameFromFiber() instead.
|
|
|
|
|
export default function getComponentNameFromType(type: mixed): string | null {
|
2018-07-12 15:32:06 +01:00
|
|
|
if (type == null) {
|
|
|
|
|
// Host root, text node or just invalid type.
|
|
|
|
|
return null;
|
|
|
|
|
}
|
2017-12-12 15:04:40 -08:00
|
|
|
if (typeof type === 'function') {
|
2024-01-11 17:24:26 -05:00
|
|
|
if ((type: any).$$typeof === REACT_CLIENT_REFERENCE) {
|
|
|
|
|
// TODO: Create a convention for naming client references with debug info.
|
|
|
|
|
return null;
|
|
|
|
|
}
|
2020-01-24 10:52:38 -08:00
|
|
|
return (type: any).displayName || type.name || null;
|
2017-12-12 15:04:40 -08:00
|
|
|
}
|
2017-10-02 13:43:45 +01:00
|
|
|
if (typeof type === 'string') {
|
|
|
|
|
return type;
|
2017-01-23 17:11:10 -08:00
|
|
|
}
|
2017-12-12 15:04:40 -08:00
|
|
|
switch (type) {
|
|
|
|
|
case REACT_FRAGMENT_TYPE:
|
2018-07-12 15:32:06 +01:00
|
|
|
return 'Fragment';
|
2018-05-10 15:25:32 -07:00
|
|
|
case REACT_PROFILER_TYPE:
|
2020-09-21 09:35:21 -03:00
|
|
|
return 'Profiler';
|
2018-05-10 15:25:32 -07:00
|
|
|
case REACT_STRICT_MODE_TYPE:
|
|
|
|
|
return 'StrictMode';
|
2018-10-10 17:02:04 +01:00
|
|
|
case REACT_SUSPENSE_TYPE:
|
|
|
|
|
return 'Suspense';
|
2019-06-19 19:34:28 -07:00
|
|
|
case REACT_SUSPENSE_LIST_TYPE:
|
|
|
|
|
return 'SuspenseList';
|
2025-03-17 09:17:00 -04:00
|
|
|
case REACT_ACTIVITY_TYPE:
|
|
|
|
|
return 'Activity';
|
Add <ViewTransition> Component (#31975)
This will provide the opt-in for using [View
Transitions](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API)
in React.
View Transitions only trigger for async updates like `startTransition`,
`useDeferredValue`, Actions or `<Suspense>` revealing from fallback to
content. Synchronous updates provide an opt-out but also guarantee that
they commit immediately which View Transitions can't.
There's no need to opt-in to View Transitions at the "cause" side like
event handlers or actions. They don't know what UI will change and
whether that has an animated transition described.
Conceptually the `<ViewTransition>` component is like a DOM fragment
that transitions its children in its own isolate/snapshot. The API works
by wrapping a DOM node or inner component:
```js
import {ViewTransition} from 'react';
<ViewTransition><Component /></ViewTransition>
```
The default is `name="auto"` which will automatically assign a
`view-transition-name` to the inner DOM node. That way you can add a
View Transition to a Component without controlling its DOM nodes styling
otherwise.
A difference between this and the browser's built-in
`view-transition-name: auto` is that switching the DOM nodes within the
`<ViewTransition>` component preserves the same name so this example
cross-fades between the DOM nodes instead of causing an exit and enter:
```js
<ViewTransition>{condition ? <ComponentA /> : <ComponentB />}</ViewTransition>
```
This becomes especially useful with `<Suspense>` as this example
cross-fades between Skeleton and Content:
```js
<ViewTransition>
<Suspense fallback={<Skeleton />}>
<Content />
</Suspense>
</ViewTransition>
```
Where as this example triggers an exit of the Skeleton and an enter of
the Content:
```js
<Suspense fallback={<ViewTransition><Skeleton /></ViewTransition>}>
<ViewTransition><Content /></ViewTransition>
</Suspense>
```
Managing instances and keys becomes extra important.
You can also specify an explicit `name` property for example for
animating the same conceptual item from one page onto another. However,
best practices is to property namespace these since they can easily
collide. It's also useful to add an `id` to it if available.
```js
<ViewTransition name="my-shared-view">
```
The model in general is the same as plain `view-transition-name` except
React manages a set of heuristics for when to apply it. A problem with
the naive View Transitions model is that it overly opts in every
boundary that *might* transition into transitioning. This is leads to
unfortunate effects like things floating around when unrelated updates
happen. This leads the whole document to animate which means that
nothing is clickable in the meantime. It makes it not useful for smaller
and more local transitions. Best practice is to add
`view-transition-name` only right before you're about to need to animate
the thing. This is tricky to manage globally on complex apps and is not
compositional. Instead we let React manage when a `<ViewTransition>`
"activates" and add/remove the `view-transition-name`. This is also when
React calls `startViewTransition` behind the scenes while it mutates the
DOM.
I've come up with a number of heuristics that I think will make a lot
easier to coordinate this. The principle is that only if something that
updates that particular boundary do we activate it. I hope that one day
maybe browsers will have something like these built-in and we can remove
our implementation.
A `<ViewTransition>` only activates if:
- If a mounted Component renders a `<ViewTransition>` within it outside
the first DOM node, and it is within the viewport, then that
ViewTransition activates as an "enter" animation. This avoids inner
"enter" animations trigger when the parent mounts.
- If an unmounted Component had a `<ViewTransition>` within it outside
the first DOM node, and it was within the viewport, then that
ViewTransition activates as an "exit" animation. This avoids inner
"exit" animations triggering when the parent unmounts.
- If an explicitly named `<ViewTransition name="...">` is deep within an
unmounted tree and one with the same name appears in a mounted tree at
the same time, then both are activated as a pair, but only if they're
both in the viewport. This avoids these triggering "enter" or "exit"
animations when going between parents that don't have a pair.
- If an already mounted `<ViewTransition>` is visible and a DOM
mutation, that might affect how it's painted, happens within its
children but outside any nested `<ViewTransition>`. This allows it to
"cross-fade" between its updates.
- If an already mounted `<ViewTransition>` resizes or moves as the
result of direct DOM nodes siblings changing or moving around. This
allows insertion, deletion and reorders into a list to animate all
children. It is only within one DOM node though, to avoid unrelated
changes in the parent to trigger this. If an item is outside the
viewport before and after, then it's skipped to avoid things flying
across the screen.
- If a `<ViewTransition>` boundary changes size, due to a DOM mutation
within it, then the parent activates (or the root document if there are
no more parents). This ensures that the container can cross-fade to
avoid abrupt relayout. This can be avoided by using absolutely
positioned children. When this can avoid bubbling to the root document,
whatever is not animating is still responsive to clicks during the
transition.
Conceptually each DOM node has its own default that activates the parent
`<ViewTransition>` or no transition if the parent is the root. That
means that if you add a DOM node like `<div><ViewTransition><Component
/></ViewTransition></div>` this won't trigger an "enter" animation since
it was the div that was added, not the ViewTransition. Instead, it might
cause a cross-fade of the parent ViewTransition or no transition if it
had no parent. This ensures that only explicit boundaries perform coarse
animations instead of every single node which is really the benefit of
the View Transitions model. This ends up working out well for simple
cases like switching between two pages immediately while transitioning
one floating item that appears on both pages. Because only the floating
item transitions by default.
Note that it's possible to add manual `view-transition-name` with CSS or
`style={{ viewTransitionName: 'auto' }}` that always transitions as long
as something else has a `<ViewTransition>` that activates. For example a
`<ViewTransition>` can wrap a whole page for a cross-fade but inside of
it an explicit name can be added to something to ensure it animates as a
move when something relates else changes its layout. Instead of just
cross-fading it along with the Page which would be the default.
There's more PRs coming with some optimizations, fixes and expanded
APIs. This first PR explores the above core heuristic.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <silbermann.sebastian@gmail.com>
2025-01-08 12:11:18 -05:00
|
|
|
case REACT_VIEW_TRANSITION_TYPE:
|
|
|
|
|
if (enableViewTransition) {
|
|
|
|
|
return 'ViewTransition';
|
|
|
|
|
}
|
|
|
|
|
// Fall through
|
2022-02-11 11:42:55 -05:00
|
|
|
case REACT_TRACING_MARKER_TYPE:
|
2022-03-07 21:13:22 -08:00
|
|
|
if (enableTransitionTracing) {
|
|
|
|
|
return 'TracingMarker';
|
|
|
|
|
}
|
2016-10-30 00:43:34 +01:00
|
|
|
}
|
2018-07-12 15:32:06 +01:00
|
|
|
if (typeof type === 'object') {
|
2024-01-11 17:24:26 -05:00
|
|
|
if (__DEV__) {
|
|
|
|
|
if (typeof (type: any).tag === 'number') {
|
|
|
|
|
console.error(
|
|
|
|
|
'Received an unexpected object in getComponentNameFromType(). ' +
|
|
|
|
|
'This is likely a bug in React. Please file an issue.',
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-04-12 09:39:05 -07:00
|
|
|
switch (type.$$typeof) {
|
2025-03-17 11:23:28 -04:00
|
|
|
case REACT_PORTAL_TYPE:
|
|
|
|
|
return 'Portal';
|
2018-07-12 15:32:06 +01:00
|
|
|
case REACT_CONTEXT_TYPE:
|
2020-03-05 10:13:52 -08:00
|
|
|
const context: ReactContext<any> = (type: any);
|
2025-06-11 12:08:04 -04:00
|
|
|
return getContextName(context);
|
2024-02-13 15:04:49 +00:00
|
|
|
case REACT_CONSUMER_TYPE:
|
2025-06-11 11:53:04 -04:00
|
|
|
const consumer: ReactConsumerType<any> = (type: any);
|
|
|
|
|
return getContextName(consumer._context) + '.Consumer';
|
2018-04-12 09:39:05 -07:00
|
|
|
case REACT_FORWARD_REF_TYPE:
|
2018-10-12 03:15:14 +01:00
|
|
|
return getWrappedName(type, type.render, 'ForwardRef');
|
2018-10-20 12:46:23 -04:00
|
|
|
case REACT_MEMO_TYPE:
|
2021-05-04 11:40:16 -04:00
|
|
|
const outerName = (type: any).displayName || null;
|
|
|
|
|
if (outerName !== null) {
|
|
|
|
|
return outerName;
|
|
|
|
|
}
|
|
|
|
|
return getComponentNameFromType(type.type) || 'Memo';
|
2018-10-18 19:57:12 -07:00
|
|
|
case REACT_LAZY_TYPE: {
|
2020-03-22 21:53:05 -07:00
|
|
|
const lazyComponent: LazyComponent<any, any> = (type: any);
|
2020-04-01 12:35:52 -07:00
|
|
|
const payload = lazyComponent._payload;
|
|
|
|
|
const init = lazyComponent._init;
|
2020-03-22 21:53:05 -07:00
|
|
|
try {
|
2021-03-05 16:02:02 -05:00
|
|
|
return getComponentNameFromType(init(payload));
|
2020-03-22 21:53:05 -07:00
|
|
|
} catch (x) {
|
|
|
|
|
return null;
|
2018-10-18 19:57:12 -07:00
|
|
|
}
|
2019-04-03 12:24:25 +01:00
|
|
|
}
|
Accept promise as element type (#13397)
* Accept promise as element type
On the initial render, the element will suspend as if a promise were
thrown from inside the body of the unresolved component. Siblings should
continue rendering and if the parent is a Placeholder, the promise
should be captured by that Placeholder.
When the promise resolves, rendering resumes. If the resolved value
has a `default` property, it is assumed to be the default export of
an ES module, and we use that as the component type. If it does not have
a `default` property, we use the resolved value itself.
The resolved value is stored as an expando on the promise/thenable.
* Use special types of work for lazy components
Because reconciliation is a hot path, this adds ClassComponentLazy,
FunctionalComponentLazy, and ForwardRefLazy as special types of work.
The other types are not supported, but wouldn't be placed into a
separate module regardless.
* Resolve defaultProps for lazy types
* Remove some calls to isContextProvider
isContextProvider checks the fiber tag, but it's typically called after
we've already refined the type of work. We should get rid of it. I
removed some of them in the previous commit, and deleted a few more
in this one. I left a few behind because the remaining ones would
require additional refactoring that feels outside the scope of this PR.
* Remove getLazyComponentTypeIfResolved
* Return baseProps instead of null
The caller compares the result to baseProps to see if anything changed.
* Avoid redundant checks by inlining getFiberTagFromObjectType
* Move tag resolution to ReactFiber module
* Pass next props to update* functions
We should do this with all types of work in the future.
* Refine component type before pushing/popping context
Removes unnecessary checks.
* Replace all occurrences of _reactResult with helper
* Move shared thenable logic to `shared` package
* Check type of wrapper object before resolving to `default` export
* Return resolved tag instead of reassigning
2018-08-16 09:21:59 -07:00
|
|
|
}
|
2018-04-12 09:39:05 -07:00
|
|
|
}
|
2017-01-25 15:49:19 +01:00
|
|
|
return null;
|
2016-10-30 00:43:34 +01:00
|
|
|
}
|
