ViewTransition uses the `useId` algorithm to auto-assign names. This
ensures that we could animate between SSR content and client content by
ensuring that the names line up.
However, I missed that we need to bump the id (materialize it) when we
do that. This is what function components do if they use one or more
`useId()`. This caused duplicate names when two ViewTransitions were
nested without any siblings since they would share name.
This PR separates Activity to it's own element type separate from
Offscreen. The goal is to allow us to add Activity element boundary
semantics during hydration similar to Suspense semantics, without
impacting the Offscreen behavior in suspended children.
This is used to register Server References that exist in the current
environment but also exists in the server it might call into. Such as a
remote server.
If the value comes from the remote server in the first place then this
is called automatically to ensure that you can pass a reference back to
where it came from - even if the `serverModuleMap` option is used. This
was already the case when `serverModuleMap` wasn't passed. This is how
you can pass server references back to the server. However, when we
added `serverModuleMap` that pass was skipped because we were getting
real functions instead of proxies.
For functions that wasn't yet passed from the remote server to the
current server, we can register them eagerly just like we do for
`import('/server').registerServerReference()`. You can now also do this
with `import('/client').registerServerReference()`. We could make them
shared so you only have to do this once but it might not be possible to
pass to the remote server and the remote server might not even be the
same RSC renderer. Therefore I split them. It's up to the compiler
whether it should do that or not. It has to know that any function you
might call might be able to receive it. This is currently global to a
specific RSC renderer.
This Hook will be used to drive a View Transition based on a gesture.
```js
const [value, startGesture] = useSwipeTransition(prev, current, next);
```
The `enableSwipeTransition` flag will depend on `enableViewTransition`
flag but we may decide to ship them independently. This PR doesn't do
anything interesting yet. There will be a lot more PRs to build out the
actual functionality. This is just wiring up the plumbing for the new
Hook.
This first PR is mainly concerned with how the whole starts (and stops).
The core API is the `startGesture` function (although there will be
other conveniences added in the future). You can call this to start a
gesture with a source provider. You can call this multiple times in one
event to batch multiple Hooks listening to the same provider. However,
each render can only handle one source provider at a time and so it does
one render per scheduled gesture provider.
This uses a separate `GestureLane` to drive gesture renders by marking
the Hook as having an update on that lane. Then schedule a render. These
renders should be blocking and in the same microtask as the
`startGesture` to ensure it can block the paint. So it's similar to
sync.
It may not be possible to finish it synchronously e.g. if something
suspends. If so, it just tries again later when it can like any other
render. This can also happen because it also may not be possible to
drive more than one gesture at a time like if we're limited to one View
Transition per document. So right now you can only run one gesture at a
time in practice.
These renders never commit. This means that we can't clear the
`GestureLane` the normal way. Instead, we have to clear only the root's
`pendingLanes` if we don't have any new renders scheduled. Then wait
until something else updates the Fiber after all gestures on it have
stopped before it really clears.
follow up to https://github.com/facebook/react/pull/32163
This continues the work of making Suspense workable anywhere in a
react-dom tree. See the prior PRs for how we handle server rendering and
client rendering. In this change we update the hydration implementation
to be able to locate expected nodes. In particular this means hydration
understands now that the default hydration context is the document body
when the container is above the body.
One case that is unique to hydration is clearing Suspense boundaries.
When hydration fails or when the server instructs the client to recover
an errored boundary it's possible that the html, head, and body tags in
the initial document were written from a fallback or a different primary
content on the server and need to be replaced by the client render.
However these tags (and in the case of head, their content) won't be
inside the comment nodes that identify the bounds of the Suspense
boundary. And when client rendering you may not even render the same
singletons that were server rendered. So when server rendering a
boudnary which contributes to the preamble (the html, head, and body tag
openings plus the head contents) we emit a special marker comment just
before closing the boundary out. This marker encodes which parts of the
preamble this boundary owned. If we need to clear the suspense boundary
on the client we read this marker and use it to reset the appropriate
singleton state.
Typed errors is not a feature that Flight currently supports. However,
for presentation purposes, serializing a custom error name is something
we could support today.
With this PR, we're now transporting custom error names through the
server-client boundary, so that they are available in the client e.g.
for console replaying. One example where this can be useful is when you
want to print debug information while leveraging the fact that
`console.warn` displays the error stack, including handling of hiding
and source mapping stack frames. In this case you may want to show
`Warning: ...` or `Debug: ...` instead of `Error: ...`.
In prod mode, we still transport an obfuscated error that uses the
default `Error` name, to not leak any sensitive information from the
server to the client. This also means that you must not rely on the
error name to discriminate errors, e.g. when handling them in an error
boundary.
Suspense is meant to be composable but there has been a lonstanding
limitation with using Suspense above the `<body>` tag of an HTML
document due to peculiarities of how HTML is parsed. For instance if you
used Suspense to render an entire HTML document and had a fallback that
might flush an alternate Document the comment nodes which describe this
boundary scope won't be where they need to be in the DOM for client
React to properly hydrate them. This is somewhat a problem of our own
making in that we have a concept of a Preamble and we leave the closing
body and html tags behind until streaming has completed which produces a
valid HTML document that also matches the DOM structure that would be
parsed from it. However Preambles as a concept are too important to
features like Float to imagine moving away from this model and so we can
either choose to just accept that you cannot use Suspense anywhere
except inside the `<body>` or we can build special support for Suspense
into react-dom that has a coherent semantic with how HTML documents are
written and parsed.
This change implements Suspense support for react-dom/server by
correctly serializing boundaries during rendering, prerendering, and
resumgin on the server. It does not yet support Suspense everywhere on
the client but this will arrive in a subsequent change. In practice
Suspense cannot be used above the `<body>` tag today so this is not a
breaking change since no programs in the wild could be using this
feature anyway.
React's streaming rendering of HTML doesn't lend itself to replacing the
contents of the documentElement, head, or body of a Document. These are
already special cased in fiber as HostSingletons and similarly for Fizz
the values we render for these tags must never be updated by the Fizz
runtime once written. To accomplish these we redefine the Preamble as
the tags that represent these three singletons plus the contents of the
document.head. If you use Suspense above any part of the Preamble then
nothing will be written to the destination until the boundary is no
longer pending. If the boundary completes then the preamble from within
that boudnary will be output. If the boundary postpones or errors then
the preamble from the fallback will be used instead.
Additionally, by default anything that is not part of the preamble is
implicitly in body scope. This leads to the somewhat counterintuitive
consequence that the comment nodes we use to mark the borders of a
Suspense boundary in Fizz can appear INSIDE the preamble that was
rendered within it.
```typescript
render((
<Suspense>
<html lang="en">
<body>
<div>hello world</div>
</body>
</html>
</Suspense>
))
```
will produce an HTML document like this
```html
<!DOCTYPE html>
<html lang="en">
<head></head>
<body>
<!--$--> <-- this is the comment Node representing the outermost Suspense
<div>hello world</div>
<$--/$-->
</body>
</html>
```
Later when I update Fiber to support Suspense anywhere hydration will
similarly start implicitly in the document body when the root is part of
the preamble (the document or one of it's singletons).
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>
The public API has been deleted a long time ago so this should be unused
unless it's used by hacks. It should be replaced with an
effect/lifecycle that manually tracks this if you need it.
The problem with this API is how the timing implemented because it
requires Placement/Hydration flags to be cleared too early. In fact,
that's why we also have a separate PlacementDEV flag that works
differently.
https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberCommitWork.js#L2157-L2165
We should be able to remove this code now.
We might have already resolved models that are not pending and so are
not rejected by aborting the stream. When those later get parsed they
might discover new chunks which end up as pending. These should be
errored since they will never be able to resolve later.
This avoids infinitely hanging the stream.
This same fix needs to be ported to ReactFlightClient that has the same
issue.
Before calling `emitTimingChunk` inside of `forwardDebugInfo`, we must
not increment `request.pendingChunks`, as this is already done inside of
the `emitTimingChunk` function.
I don't have a unit test for this, but manually verified that this fixes
the hanging responses in https://github.com/vercel/next.js/pull/73804.
We're seeing errors when testing useResourceEffect in SSR and it turns
out we're missing the noop dispatcher function on Fizz.
I tested a local build with this change and it resolved the late
mutation errors in the e2e tests.
This adds a new `react-server-dom-parcel-package`, which is an RSC
integration for the Parcel bundler. It is mostly copied from the
existing webpack/turbopack integrations, with some changes to utilize
Parcel runtime APIs for loading and executing bundles/modules.
See https://github.com/parcel-bundler/parcel/pull/10043 for the Parcel
side of this, which includes the plugin needed to generate client and
server references. https://github.com/parcel-bundler/rsc-examples also
includes examples of various ways to use RSCs with Parcel.
Differences from other integrations:
* Client and server modules are all part of the same graph, and we use
Parcel's
[environments](https://parceljs.org/plugin-system/transformer/#the-environment)
to distinguish them. The server is the Parcel build entry point, and it
imports and renders server components in route handlers. When a `"use
client"` directive is seen, the environment changes and Parcel creates a
new client bundle for the page, combining all client modules together.
CSS from both client and server components are also combined
automatically.
* There is no separate manifest file that needs to be passed around by
the user. A [Runtime](https://parceljs.org/plugin-system/runtime/)
plugin injects client and server references as needed into the relevant
bundles, and registers server action ids using `react-server-dom-parcel`
automatically.
* A special `<Resources>` component is also generated by Parcel to
render the `<script>` and `<link rel="stylesheet">` elements needed for
a page, using the relevant info from the bundle graph.
Note: I've already published a 0.0.x version of this package to npm for
testing purposes but happy to add whoever needs access to it as well.
### Questions
* How to test this in the React repo. I'll have integration tests in
Parcel, but setting up all the different mocks and environments to
simulate that here seems challenging. I could try to copy how
Webpack/Turbopack do it but it's a bit different.
* Where to put TypeScript types. Right now I have some ambient types in
my [example
repo](https://github.com/parcel-bundler/rsc-examples/blob/main/types.d.ts)
but it would be nice for users not to copy and paste these. Can I
include them in the package or do they need to maintained separately in
definitelytyped? I would really prefer not to have to maintain code in
three different repos ideally.
---------
Co-authored-by: Sebastian Markbage <sebastian@calyptus.eu>
Stacked on #31715.
This adds profiling data for Server Components to the RSC stream (but
doesn't yet use it for anything). This is on behind
`enableProfilerTimer` which is on for Dev and Profiling builds. However,
for now there's no Profiling build of Flight so in practice only in DEV.
It's gated on `enableComponentPerformanceTrack` which is experimental
only for now.
We first emit a timeOrigin in the beginning of the stream. This provides
us a relative time to emit timestamps against for cross environment
transfer so that we can log it in terms of absolute times. Using this as
a separate field allows the actual relative timestamps to be a bit more
compact representation and preserves floating point precision.
We emit a timestamp before emitting a Server Component which represents
the start time of the Server Component. The end time is either when the
next Server Component starts or when we finish the task.
We omit the end time for simple tasks that are outlined without Server
Components.
By encoding this as part of the debugInfo stream, this information can
be forwarded between Server to Server RSC.
We shouldn't call onError/onPostpone when we halt a stream because that
node didn't error yet. Its digest would also get lost.
We also have a lot of error branches now for thenables and streams. This
unifies them under erroredTask. I'm not yet unifying the cases that
don't allocate a task for the error when those are outlined.
This clarifies a few things by ensuring that there is always at least
one required field. This can be used to refine the object to one of the
specific types. However, it's probably just a matter of time until we
make this tagged unions instead. E.g. it would be nice to rename the
`name` field `ReactComponentInfo` to `type` and tag it with the React
Element symbol because then it's just the same as a React Element.
I also extract a time field. The idea is that this will advance (or
rewind) the time to the new timestamp and then anything below would be
defined as happening within that time stamp. E.g. to model the start and
end for a server component you'd do something like:
```
[
{time: 123},
{name: 'Component', ... },
{time: 124},
]
```
The reason this needs to be in the `ReactDebugInfo` is so that timing
information from one environment gets transferred into the next
environment. It lets you take a Promise from one world and transfer it
into another world and its timing information is preserved without
everything else being preserved.
I've gone back and forth on if this should be part of each other Info
object like `ReactComponentInfo` but since those can be deduped and can
change formats (e.g. this should really just be a React Element) it's
better to store this separately.
The time format is relative to a `timeOrigin` which is the current
environment's `timeOrigin`. When it's serialized between environments
this needs to be considered.
Emitting these timings is not yet implemented in this PR.
---------
Co-authored-by: eps1lon <sebastian.silbermann@vercel.com>
This is just moving some code into a helper.
We have a bunch of special cases for the return value slot of a Server
Component that's different from just rendering that inside an object.
This was getting a little tricky to reason about inline with the rest of
rendering.
Hints and Console logs are side-effects and don't belong to any
particular value. They're `void`. Therefore they don't need a row ID.
In the current parsing scheme it's ok to omit the id. It just becomes
`0` which is the initial value which is then unused for these row types.
So it looks like:
```
:HP[...]
:W[...]
0:{...}
```
We could patch the parsing to encode the tag in the ID so it's more like
the ID is the target of the side-effect.
```
H:P[...]
W:[...]
0:{...}
```
Or move the tagging to the beginning like it used to be.
But this seems simple enough for now.
This lets us track separately if something was suspended on an Action
using useActionState rather than suspended on Data.
This approach feels quite bloated and it seems like we'd eventually
might want to read more information about the Promise that suspended and
the context it suspended in. As a more general reason for suspending.
The way useActionState works in combination with the prewarming is quite
unfortunate because 1) it renders blocking to update the isPending flag
whether you use it or not 2) it prewarms and suspends the useActionState
3) then it does another third render to get back into the useActionState
position again.
This readme documents React Server Components from `react-server`
package enough to get an implementer started. It's not comprehensive but
it's a beginning point and crucially adds documentation for the
`prerender` API for Flight.
We don't actually want the source mapped version of `.stack` from errors
because that would cause us to not be able to associate it with a source
map in the UIs that need it. The strategy in browsers is more correct
where the display is responsible for source maps.
That's why we disable any custom `prepareStackTrace` like the ones added
by `source-map`. We reset it to `undefined`.
However, when running node with `--enable-source-maps` the default for
`prepareStackTrace` which is a V8 feature (but may exist elsewhere too
like Bun) is a source mapped version of the stack. In those environments
we need to reset it to a default implementation that doesn't apply
source maps.
We already did this in Flight using the `ReactFlightStackConfigV8.js`
config. However, we need this more generally in the
`shared/ReactComponentStackFrame` implementation.
We could always set it to the default implementation instead of
`undefined` but that's unnecessary code in browser builds and it might
lead to slightly different results. For safety and code size, this PR
does it with a fork instead.
All builds specific to `node` or `edge` (or `markup` which is a server
feature) gets the default implementation where as everything else (e.g.
browsers) get `undefined` since it's expected that this is not source
mapped. We don't have to do anything about the equivalent in React
DevTools since React DevTools doesn't run on the server.
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development --persistent, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development --persistent, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development --persistent, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development --persistent, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development --persistent, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=development, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=production, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=production, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=production, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=production, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=experimental --env=production, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=stable --env=development --persistent, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=stable --env=development --persistent, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=stable --env=development --persistent, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=stable --env=development --persistent, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=stable --env=development --persistent, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=false, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=false, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=false, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=false, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=false, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=true, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=true, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=true, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=true, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=development --variant=true, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=false, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=false, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=false, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=false, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=false, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=true, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=true, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=true, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=true, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-classic --env=production --variant=true, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=false, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=false, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=false, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=false, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=false, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=true, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=true, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=true, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=true, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=development --variant=true, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=false, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=false, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=false, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=false, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=false, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=true, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=true, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=true, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=true, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=www-modern --env=production --variant=true, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=false, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=false, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=false, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=false, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=false, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=true, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=true, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=true, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=true, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=development --variant=true, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=false, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=false, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=false, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=false, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=false, 5/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=true, 1/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=true, 2/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=true, 3/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=true, 4/5) (push) Has been cancelled
(Runtime) Build and Test / yarn test ${{ matrix.params }} (Shard ${{ matrix.shard }}) (-r=xplat --env=production --variant=true, 5/5) (push) Has been cancelled
When we serialize debug info we should never error even though we don't
currently support everything being serialized. Since it's non-essential
dev information.
We already handle errors in the replacer but not when errors happen in
the JSON algorithm itself - such as cyclic errors.
We should ideally support cyclic objects but regardless we should
gracefully handle the errors.
Normally we filter out stack frames with missing `filename` because they
can be noisy and not ignore listed. However, it's up to the
filterStackFrame function to determine whether to do it. This lets us
match `<anonymous>` stack frames in V8 parsing (they don't have line
numbers).
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn test --debug --watch TestName`,
open `chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
In order to adopt react 19's ref-as-prop model, Flow needs to eliminate
all the places where they are treated differently.
`React.AbstractComponent` is the worst example of this, and we need to
eliminate it.
This PR eliminates them from the react repo, and only keeps the one that
has 1 argument of props.
## How did you test this change?
yarn flow
When aborting we emit chunks for each pending task. However there was a
bug where a thenable could also reject before we could flush and we end
up with an extra chunk throwing off the pendingChunks bookeeping. When a
task is retried we skip it if is is not in PENDING status because we
understand it was completed some other way. We need to replciate this
for the reject pathway on serialized thenables since aborting if
effectively completing all pending tasks and not something we need to
continue to do once the thenable rejects later.
We can't make a special getter to mark the boundary of deep
serialization (which can be used for lazy loading in the future) when
the parent object is a special object that we parse with
getOutlinedModel. Such as Map/Set and JSX.
This marks the objects that are direct children of those as not possible
to limit.
I don't love this solution since ideally it would maybe be more local to
the serialization of a specific object.
It also means that very deep trees of only Map/Set never get cut off.
Maybe we should instead override the `get()` and enumeration methods on
these instead somehow.
It's important to have it be a getter though because that's the
mechanism that lets us lazy-load more depth in the future.
renderModelDesctructive can sometimes be called direclty on Date values.
When this happens we don't first call toJSON on the Date value so we
need to explicitly handle the case where where the rendered value is a
Date instance as well. This change updates renderModelDesctructive to
account for sometimes receiving Date instances directly.
This allows us to show props in React DevTools when inspecting a Server
Component.
I currently drastically limit the object depth that's serialized since
this is very implicit and you can have heavy objects on the server.
We previously was using the general outlineModel to outline
ReactComponentInfo but we weren't consistently using it everywhere which
could cause some bugs with the parsing when it got deduped on the
client. It also lead to the weird feature detect of `isReactComponent`.
It also meant that this serialization was using the plain serialization
instead of `renderConsoleValue` which means we couldn't safely serialize
arbitrary debug info that isn't serializable there.
So the main change here is to call `outlineComponentInfo` and have that
always write every "Server Component" instance as outlined and in a way
that lets its props be serialized using `renderConsoleValue`.
<img width="1150" alt="Screenshot 2024-10-01 at 1 25 05 AM"
src="https://github.com/user-attachments/assets/f6e7811d-51a3-46b9-bbe0-1b8276849ed4">
The idea is that the RSC protocol is a superset of Structured Clone.
#25687 One exception that we left out was serializing Error objects as
values. We serialize "throws" or "rejections" as Error (regardless of
their type) but not Error values.
This fixes that by serializing `Error` objects. We don't include digest
in this case since we don't call `onError` and it's not really expected
that you'd log it on the server with some way to look it up.
In general this is not super useful outside throws. Especially since we
hide their values in prod. However, there is one case where it is quite
useful. When you replay console logs in DEV you might often log an Error
object within the scope of a Server Component. E.g. the default RSC
error handling just console.error and error object.
Before this would just be an empty object due to our lax console log
serialization:
<img width="1355" alt="Screenshot 2024-09-30 at 2 24 03 PM"
src="https://github.com/user-attachments/assets/694b3fd3-f95f-4863-9321-bcea3f5c5db4">
After:
<img width="1348" alt="Screenshot 2024-09-30 at 2 36 48 PM"
src="https://github.com/user-attachments/assets/834b129d-220d-43a2-a2f4-2eb06921747d">
TODO for a follow up: Flight Reply direction. This direction doesn't
actually serialize thrown errors because they always reject the
serialization.
