This adds some I/O to go get the third party thing to test how it
overlaps.
With #33482, this is what it looks like. The await gets cut off when the
third party component starts rendering. I.e. after the latency to start.
<img width="735" alt="Screenshot 2025-06-08 at 5 42 46 PM"
src="https://github.com/user-attachments/assets/f68d9a84-05a1-4125-b3f0-8f3e4eaaa5c1"
/>
This doesn't fully simulate everything because it should actually also
simulate each chunk of the stream coming back too. We could wrap the
ReadableStream to simulate that. In that scenario, it would probably get
some awaits on the chunks at the end too.
## Summary
In react-native props that are passed as function get converted to a
boolean (`true`). This is the default pattern for event handlers in
react-native.
However, there are reasons for why you might want to opt-out of this
behavior, and instead, pass along the actual function as the prop.
Right now, there is no way to do this, and props that are functions
always get set to `true`.
The `ViewConfig` attributes already have the API for a `process`
function. I simply moved the check for the process function up, so if a
ViewConfig's prop attribute configured a process function this is always
called first.
This provides an API to opt out of the default behavior.
This is the accompanied PR for react-native:
- https://github.com/facebook/react-native/pull/48777
## How did you test this change?
<!--
Demonstrate the code is solid. Example: The exact commands you ran and
their output, screenshots / videos if the pull request changes the user
interface.
How exactly did you verify that your PR solves the issue you wanted to
solve?
If you leave this empty, your PR will very likely be closed.
-->
I modified the code manually in a template react-native app and
confirmed its working. This is a code path you only need in very special
cases, thus it's a bit hard to provide a test for this. I recorded a
video where you can see that the changes are active and the prop is
being passed as native value.
For this I created a custom native component with a view config that
looked like this:
```js
const viewConfig = {
uiViewClassName: 'CustomView',
bubblingEventTypes: {},
directEventTypes: {},
validAttributes: {
nativeProp: {
process: (nativeProp) => {
// Identity function that simply returns the prop function callback
// to opt out of this prop being set to `true` as its a function
return nativeProp
},
},
},
}
```
https://github.com/user-attachments/assets/493534b2-a508-4142-a760-0b1b24419e19
Additionally I made sure that this doesn't conflict with any existing
view configs in react native. In general, this shouldn't be a breaking
change, as for existing view configs it didn't made a difference if you
simply set `myProp: true` or `myProp: { process: () => {...} }` because
as soon as it was detected that the prop is a function the config
wouldn't be used (which is what this PR fixes).
Probably everyone, including the react-native core components use
`myProp: true` for callback props, so this change should be fine.
Technically the async call graph spans basically all the way back to the
start of the app potentially, but we don't want to include everything.
Similarly we don't want to include everything from previous components
in every child component. So we need some heuristics for filtering out
data.
We roughly want to be able to inspect is what might contribute to a
Suspense loading sequence even if it didn't this time e.g. due to a race
condition.
One flaw with the previous approach was that awaiting a cached promise
in a sibling that happened to finish after another sibling would be
excluded. However, in a different race condition that might end up being
used so I wanted to include an empty "await" in that scenario to have
some association from that component.
However, for data that resolved fully before the request even started,
it's a little different. This can be things that are part of the start
up sequence of the app or externally cached data. We decided that this
should be excluded because it doesn't contribute to the loading sequence
in the expected scenario. I.e. if it's cached. Things that end up being
cache misses would still be included. If you want to test externally
cached data misses, then it's up to you or the framework to simulate
those. E.g. by dropping the cache. This also helps free up some noise
since static / cached data can be excluded in visualizations.
I also apply this principle to forwarding debug info. If you reuse a
cached RSC payload, then the Server Component render time and its awaits
gets clamped to the caller as if it has zero render/await time. The I/O
entry is still back dated but if it was fully resolved before we started
then it's completely excluded.
I noticed that the ThirdPartyComponent in the fixture was showing the
wrong stack and the `"use third-party"` is in the wrong location.
<img width="628" alt="Screenshot 2025-06-06 at 11 22 11 PM"
src="https://github.com/user-attachments/assets/f0013380-d79e-4765-b371-87fd61b3056b"
/>
When creating the initial JSX inside the third party server, we should
make sure that it has no owner. In a real cross-server environment you
get this by default by just executing in different context. But since
the fixture example is inside the same AsyncLocalStorage as the parent
it already has an owner which gets transferred. So we should make sure
that were we create the JSX has no owner to simulate this.
When we then parse a null owner on the receiving side, we replace its
owner/stack with the owner/stack of the call to `createFrom...` to
connect them. This worked fine with only two environments. The bug was
that when we did this and then transferred the result to a third
environment we took the original parsed stack trace. We should instead
parse a new one from the replaced stack in the current environment.
The second bug was that the `"use third-party"` badge ends up in the
wrong place when we do this kind of thing. Because the stack of the
thing entering the new environment is the call to `createFrom...` which
is in the old environment even though the component itself executes in
the new environment. So to see if there's a change we should be
comparing the current environment of the task to the owner's environment
instead of the next environment after the task.
After:
<img width="494" alt="Screenshot 2025-06-07 at 1 13 28 AM"
src="https://github.com/user-attachments/assets/e2e870ba-f125-4526-a853-bd29f164cf09"
/>
This effectively lets us consume Web Streams in a Node build. In fact
the Node entry point is now just adding Node stream APIs.
For the client, this is simple because the configs are not actually
stream type specific. The server is a little trickier.
Reverts #33457, #33456 and #33442.
There are too many issues with wrappers, lazy init, stateful modules,
duplicate instantiation of async_hooks and duplication of code.
Instead, we'll just do a wrapper polyfill that uses Node Streams
internally.
I kept the client indirection files that I added for consistency with
the server though.
When deeply nested Suspense boundaries inside a fallback of another
boundary resolve it is possible to encounter situations where you either
attempt to flush an aborted Segment or you have a boundary without any
root segment. We intended for both of these conditions to be impossible
to arrive at legitimately however it turns out in this situation you
can. The fix is two-fold
1. allow flushing aborted segments by simply skipping them. This does
remove some protection against future misconfiguraiton of React because
it is no longer an invariant that you hsould never attempt to flush an
aborted segment but there are legitimate cases where this can come up
and simply omitting the segment is fine b/c we know that the user will
never observe this. A semantically better solution would be to avoid
flushing boudaries inside an unneeded fallback but to do this we would
need to track all boundaries inside a fallback or create back pointers
which add to memory overhead and possibly make GC harder to do
efficiently. By flushing extra we're maintaining status quo and only
suffer in performance not with broken semantics.
2. when queuing completed segments allow for queueing aborted segments
and if we are eliding the enqueued segment allow for child segments that
are errored to be enqueued too. This will mean that we can maintain the
invariant that a boundary must have a root segment the first time we
flush it, it just might be aborted (see point 1 above).
This change has two seemingly similar test cases to exercise this fix.
The reason we need both is that when you have empty segments you hit
different code paths within Fizz and so each one (without this fix)
triggers a different error pathway.
This change also includes a fix to our tests where we were not
appropriately setting CSPnonce back to null at the start of each test so
in some contexts scripts would not run for some tests
Adding throttling or delaying on images, can obviously impact metrics.
However, it's all in the name of better actual user experience overall.
(Note that it's not strictly worse even for metric. Often it's actually
strictly better due to less work being done overall thanks to batching.)
Metrics can impact things like search ranking but I believe this is on a
curve. If you're already pretty good, then a slight delay won't suddenly
make you rank in a completely different category. Similarly, if you're
already pretty bad then a slight delay won't make it suddenly way worse.
It's still in the same realm. It's just one weight of many. I don't
think this will make a meaningful practical impact and if it does,
that's probably a bug in the weights that will get fixed.
However, because there's a race to try to "make everything green" in
terms of web vitals, if you go from green to yellow only because of some
throttling or suspensey images, it can feel bad. Therefore this
implements a heuristic where if the only reason we'd miss a specific
target is because of throttling or suspensey images, then we shorten the
timeout to hit the metric. This is a worse user experience because it
can lead to extra flashing but feeling good about "green" matters too.
If you then have another reveal that happens to be the largest
contentful paint after that, then that's throttled again so that it
doesn't become flashy after that. If you've already missed the deadline
then you're not going to hit your metric target anyway. It can affect
average but not median.
This is mainly about LCP. It doesn't affect FCP since that doesn't have
a throttle. If your LCP is the same as your FCP then it also doesn't
matter.
We assume that `performance.now()`'s zero point starts at the "start of
the navigation" which makes this simple. Even if we used the
`PerformanceNavigationTiming` API it would just tell us the same thing.
This only implements for Fizz since these metrics tend to currently only
by tracked for initial loads, but with soft navs tracking we could
consider implementing the same for Fiber throttles.
Follow up to #33442. This is the bundled version.
To keep type check passes from exploding and the maintainance of the
annoying `paths: []` list small, this doesn't add this to flow type
checks. We might miss some config but every combination should already
be covered by other one passes.
I also don't add any jest tests because to test these double export
entry points we need conditional importing to cover builds and
non-builds which turns out to be difficult for the Flight builds so
these aren't covered by any basic build tests.
This approach is what I'm going for, for the other bundlers too.
We want to make sure that we can block the reveal of a well designed
complete shell reliably. In the Suspense model, client transitions don't
have any way to implicitly resolve. This means you need to use Suspense
or SuspenseList to explicitly split the document. Relying on implicit
would mean you can't add a Suspense boundary later where needed. So we
highly encourage the use of them around large content.
However, if you have constructed a too large shell (e.g. by not adding
any Suspense boundaries at all) then that might take too long to render
on the client. We shouldn't punish users (or overzealous metrics
tracking tools like search engines) in that scenario.
This opts out of render blocking if the shell ends up too large to be
intentional and too slow to load. Instead it deopts to showing the
content split up in arbitrary ways (browser default). It only does this
for SSR, and not client navs so it's not reliable.
In fact, we issue an error to `onError`. This error is recoverable in
that the document is still produced. It's up to your framework to decide
if this errors the build or just surface it for action later.
What should be the limit though? There's a trade off here. If this limit
is too low then you can't fit a reasonably well built UI within it
without getting errors. If it's too high then things that accidentally
fall below it might take too long to load.
I came up with 512kB of uncompressed shell HTML. See the comment in code
for the rationale for this number. TL;DR: Data and theory indicates that
having this much content inside `rel="expect"` doesn't meaningfully
change metrics. Research of above-the-fold content on various websites
indicate that this can comfortable fit all of them which should be
enough for any intentional initial paint.
Block the view transition on suspensey images Up to 500ms just like the
client.
We can't use `decode()` because a bug in Chrome where those are blocked
on `startViewTransition` finishing we instead rely on sync decoding but
also that the image is live when it's animating in and we assume it
doesn't start visible.
However, we can block the View Transition from starting on the `"load"`
or `"error"` events.
The nice thing about blocking inside `startViewTransition` is that we
have already done the layout so we can only wait on images that are
within the viewport at this point. We might want to do that in Fiber
too. If many image doesn't have fixed size but need to load first, they
can all end up in the viewport. We might consider only doing this for
images that have a fixed size or only a max number that doesn't have a
fixed size.
## Summary
Enables the `enableEagerAlternateStateNodeCleanup` feature flag for all
variants, while maintaining the `__VARIANT__` for the internal React
Native flavor for backtesting reasons.
## How did you test this change?
```
$ yarn test
```
When I added the `ready_for_review` event in #32344, no notifications
for opened draft PRs were sent due to some other condition. This is not
the case anymore, so we need to exclude draft PRs from triggering a
notification when the workflow is run because of an `opened` event. This
event is still needed because the `ready_for_review` event only fires
when an existing draft PR is converted to a non-draft state. It does not
trigger for pull requests that are opened directly as ready-for-review.
We highly recommend using Node Streams in Node.js because it's much
faster and it is less likely to cause issues when chained in things like
compression algorithms that need explicit flushing which the Web Streams
ecosystem doesn't have a good solution for. However, that said, people
want to be able to use the worse option for various reasons.
The `.edge` builds aren't technically intended for Node.js. A Node.js
environments needs to be patched in various ways to support it. It's
also less optimal since it can't use [Node.js exclusive
features](https://github.com/facebook/react/pull/33388) and have to use
[the lowest common
denominator](https://github.com/facebook/react/pull/27399) such as JS
implementations instead of native.
This adds a Web Streams build of Fizz but exclusively for Node.js so
that in it we can rely on Node.js modules. The main difference compared
to Edge is that SSR now uses `createHash` from the `"crypto"` module and
imports `TextEncoder` from `"util"`. We use `setImmediate` instead of
`setTimeout`.
The public API is just `react-dom/server` which in Node.js automatically
imports `react-dom/server.node` which re-exports the legacy bundle, Node
Streams bundle and Node Web Streams bundle. The main downside is if your
bundler isn't smart to DCE this barrel file.
With Flight the difference is larger but that's a bigger lift.
Stacked on #33403.
When a Promise is coming from React such as when it's passed from
another environment, we should forward the debug information from that
environment. We already do that when rendered as a child.
This makes it possible to also `await promise` and have the information
from that instrumented promise carry through to the next render.
This is a bit tricky because the current protocol is that we have to
read it from the Promise after it resolves so it has time to be assigned
to the promise. `async_hooks` doesn't pass us the instance (even though
it has it) when it gets resolved so we need to keep it around. However,
we have to be very careful because if we get this wrong it'll cause a
memory leak since we retain things by `asyncId` and then manually listen
for `destroy()` which can only be called once a Promise is GC:ed, which
it can't be if we retain it. We have to therefore use a `WeakRef` in
case it never resolves, and then read the `_debugInfo` when it resolves.
We could maybe install a setter or something instead but that's also
heavy.
The other issues is that we don't use native Promises in
ReactFlightClient so our instrumented promises aren't picked up by the
`async_hooks` implementation and so we never get a handle to our
thenable instance. To solve this we can create a native wrapper only in
DEV.
We want to change the defaults for `revealOrder` and `tail` on
SuspenseList. This is an intermediate step to allow experimental users
to upgrade.
To explicitly specify these options I added `revealOrder="independent"`
and `tail="visible"`.
I then added warnings if `undefined` or `null` is passed. You must now
always explicitly specify them. However, semantics are still preserved
for now until the next step.
We also want to change the rendering order of the `children` prop for
`revealOrder="backwards"`. As an intermediate step I first added
`revealOrder="unstable_legacy-backwards"` option. This will only be
temporary until all users can switch to the new `"backwards"` semantics
once we flip it in the next step.
I also clarified the types that the directional props requires iterable
children but not iterable inside of those. Rows with multiple items can
be modeled as explicit fragments.
Stacked on #33402.
There's a bug in Chrome Performance tracking which uses the enclosing
line/column instead of the callsite in stacks.
For our fake eval:ed functions that represents functions on the server,
we can position the enclosing function body at the position of the
callsite to simulate getting the right line.
Unfortunately, that doesn't give us exactly the right callsite when it's
used for other purposes that uses the callsite like console logs and
error reporting and stacks inside breakpoints. So I don't think we want
to always do this.
For ReactAsyncInfo/ReactIOInfo, the only thing we're going to use the
fake task for is the Performance tracking, so it doesn't have any
downsides until Chrome fixes the bug and we'd have to revert it.
Therefore this PR uses that techniques only for those entries.
We could do this for Server Components too but we're going to use those
for other things too like console logs. I don't think it's worth
duplicating the Task objects. That would also make it inconsistent with
Client Components.
For Client Components, we could in theory also generate fake evals but
that would be way slower since there's so many of them and currently we
rely on the native implementation for those. So doesn't seem worth
fixing.
But since we can at least fix it for RSC I/O/awaits we can do this hack.
Stacked on #33400.
<img width="1261" alt="Screenshot 2025-06-01 at 10 27 47 PM"
src="https://github.com/user-attachments/assets/a5a73ee2-49e0-4851-84ac-e0df6032efb5"
/>
This is emitted with the start/end time and stack of the "await". Which
may be different than the thing that started the I/O.
These awaits aren't quite as simple as just every await since you can
start a sequence in parallel there can actually be multiple overlapping
awaits and there can be CPU work interleaved with the await on the same
component.
```js
function getData() {
await fetch(...);
await fetch(...);
}
const promise = getData();
doWork();
await promise;
```
This has two "I/O" awaits but those are actually happening in parallel
with `doWork()`.
Since these also could have started before we started rendering this
sequence (e.g. a component) we have to clamp it so that we don't
consider awaits that start before the component.
What we're conceptually trying to convey is the time this component was
blocked due to that I/O resource. Whether it's blocked from completing
the last result or if it's blocked from issuing a waterfall request.
Stacked on #33395.
This lets us keep track of which environment this was fetched and
awaited.
Currently the IO and await is in the same environment. It's just kept
when forwarded. Once we support forwarding information from a Promise
fetched from another environment and awaited in this environment then
the await can end up being in a different environment.
There's a question of when the await is inside Flight itself such as
when you return a promise fetched from another environment whether that
should mean that the await is in the current environment. I don't think
so since the original stack trace is the best stack trace. It's only if
you `await` it in user space in this environment first that this might
happen and even then it should only be considered if there wasn't a
better await earlier or if reading from the other environment was itself
I/O.
The timing of *when* we read `environmentName()` is a little interesting
here too.
Stacked on #33394.
This lets us create async stack traces to the owner that was in context
when the I/O was started or awaited.
<img width="615" alt="Screenshot 2025-06-01 at 12 31 52 AM"
src="https://github.com/user-attachments/assets/6ff5a146-33d6-4a4b-84af-1b57e73047d4"
/>
This owner might not be the immediate closest parent where the I/O was
awaited.
Stacked on #33392.
This adds another track to the Performance Track called `"Server
Requests"`.
<img width="1015" alt="Screenshot 2025-06-01 at 12 02 14 AM"
src="https://github.com/user-attachments/assets/c4d164c4-cfdf-4e14-9a87-3f011f65fd20"
/>
This logs the flat list of I/O awaited on by Server Components. There
will be other views that are more focused on what data blocks a specific
Component or Suspense boundary but this is just the list of all the I/O
basically so you can get an overview of those waterfalls without the
noise of all the Component trees and rendering. It's similar to what the
"Network" track is on the client.
I've been going back and forth on what to call this track but I went
with `"Server Requests"` for now. The idea is that the name should
communicate that this is something that happens on the server and is a
pairing with the `"Server Components"` track. Although we don't use that
feature, since it's missing granularity, it's also similar to "Server
Timings".
Stacked on #33390.
The stack trace doesn't include the thing you called when calling into
ignore listed content. We consider the ignore listed content
conceptually the abstraction that you called that's interesting.
This extracts the name of the first ignore listed function that was
called from user space. For example `"fetch"`. So we can know what kind
of request this is.
This could be enhanced and tweaked with heuristics in the future. For
example, when you create a Promise yourself and call I/O inside of it
like my `delay` examples, then we use that Promise as the I/O node but
its stack doesn't have the actual I/O performed. It might be better to
use the inner I/O node in that case. E.g. `setTimeout`. Currently I pick
the name from the first party code instead - in my example `delay`.
Another case that could be improved is the case where your whole
component is third-party. In that case we still log the I/O but it has
no context about what kind of I/O since the whole stack is ignored it
just gets the component name for example. We could for example look at
the first name that is in a different package than the package name of
the ignored listed component. So if
`node_modules/my-component-library/index.js` calls into
`node_modules/mysql/connection.js` then we could use the name from the
inner.
Stacked on #33388.
This encodes the I/O entries as their own row type (`"J"`). This makes
it possible to parse them directly without first parsing the debug info
for each component. E.g. if you're just interested in logging the I/O
without all the places it was awaited.
This is not strictly necessary since the debug info is also readily
available without parsing the actual trees. (That's how the Server
Components Performance Track works.) However, we might want to exclude
this information in profiling builds while retaining some limited form
of I/O tracking.
It also allows for logging side-effects that are not awaited if we
wanted to.
This lets us track what data each Server Component depended on. This
will be used by Performance Track and React DevTools.
We use Node.js `async_hooks`. This has a number of downside. It is
Node.js specific so this feature is not available in other runtimes
until something equivalent becomes available. It's [discouraged by
Node.js docs](https://nodejs.org/api/async_hooks.html#async-hooks). It's
also slow which makes this approach only really viable in development
mode. At least with stack traces. However, it's really the only solution
that gives us the data that we need.
The [Diagnostic
Channel](https://nodejs.org/api/diagnostics_channel.html) API is not
sufficient. Not only is many Node.js built-in APIs missing but all
libraries like databases are also missing. Were as `async_hooks` covers
pretty much anything async in the Node.js ecosystem.
However, even if coverage was wider it's not actually showing the
information we want. It's not enough to show the low level I/O that is
happening because that doesn't provide the context. We need the stack
trace in user space code where it was initiated and where it was
awaited. It's also not each low level socket operation that we want to
surface but some higher level concept which can span a sequence of I/O
operations but as far as user space is concerned.
Therefore this solution is anchored on stack traces and ignore listing
to determine what the interesting span is. It is somewhat
Promise-centric (and in particular async/await) because it allows us to
model an abstract span instead of just random I/O. Async/await points
are also especially useful because this allows Async Stacks to show the
full sequence which is not supported by random callbacks. However, if no
Promises are involved we still to our best to show the stack causing
plain I/O callbacks.
Additionally, we don't want to track all possible I/O. For example,
side-effects like logging that doesn't affect the rendering performance
doesn't need to be included. We only want to include things that
actually block the rendering output. We also need to track which data
blocks each component so that we can track which data caused a
particular subtree to suspend.
We can do this using `async_hooks` because we can track the graph of
what resolved what and then spawned what.
To track what suspended what, something has to resolve. Therefore it
needs to run to completion before we can show what it was suspended on.
So something that never resolves, won't be tracked for example.
We use the `async_hooks` in `ReactFlightServerConfigDebugNode` to build
up an `ReactFlightAsyncSequence` graph that collects the stack traces
for basically all I/O and Promises allocated in the whole app. This is
pretty heavy, especially the stack traces, but it's because we don't
know which ones we'll need until they resolve. We don't materialize the
stacks until we need them though.
Once they end up pinging the Flight runtime, we collect which current
executing task that pinged the runtime and then log the sequence that
led up until that runtime into the RSC protocol. Currently we only
include things that weren't already resolved before we started rendering
this task/component, so that we don't log the entire history each time.
Each operation is split into two parts. First a `ReactIOInfo` which
represents an I/O operation and its start/end time. Basically the start
point where it was start. This is basically represents where you called
`new Promise()` or when entering an `async function` which has an
implied Promise. It can be started in a different component than where
it's awaited and it can be awaited in multiple places. Therefore this is
global information and not associated with a specific Component.
The second part is `ReactAsyncInfo`. This represents where this I/O was
`await`:ed or `.then()` called. This is associated with a point in the
tree (usually the Promise that's a direct child of a Component). Since
you can have multiple different I/O awaited in a sequence technically it
forms a dependency graph but to simplify the model these awaits as
flattened into the `ReactDebugInfo` list. Basically it contains each
await in a sequence that affected this part from unblocking.
This means that the same `ReactAsyncInfo` can appear in mutliple
components if they all await the same `ReactIOInfo` but the same Promise
only appears once.
Promises that are only resolved by other Promises or immediately are not
considered here. Only if they're resolved by an I/O operation. We pick
the Promise basically on the border between user space code and ignored
listed code (`node_modules`) to pick the most specific span but abstract
enough to not give too much detail irrelevant to the current audience.
Similarly, the deepest `await` in user space is marked as the relevant
`await` point.
This feature is only available in the `node` builds of React. Not if you
use the `edge` builds inside of Node.js.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <silbermann.sebastian@gmail.com>
Alternative to #33421. The difference is that this also adds an
underscore between the "R" and the ID.
The reason we wanted to use special characters is because we use the
full spectrum of A-Z 0-9 in our ID generation so we can basically
collide with any common word (or anyone using a similar algorithm,
base64 or even base16). It's a little less likely that someone would put
`_R_` specifically unless you generate like two IDs separated by
underscore.
## Summary
This tool leverages DevTools to get the component tree from the
currently open React App. This gives realtime information to agents
about the state of the app.
## How did you test this change?
Tested integration with Claude Desktop
This is a babel bug + edge case.
Babel compact mode produces invalid JavaScript (i.e. parse error) when
given a `NumericLiteral` with a negative value.
See https://codesandbox.io/p/devbox/5d47fr for repro.
(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
## Summary
While investigating the root cause of #33208, I noticed a clear typo for
one of the validation files.
## How did you test this change?
Inside `/react/compiler/packages/babel-plugin-react-compiler` I ran the
test script successfully:
<img width="415" alt="Screenshot at May 22 16-43-06"
src="https://github.com/user-attachments/assets/3fe8c5e1-37ce-4a31-b35e-7e323e57cd9d"
/>
## Summary
We completed testing on these internally, so can cleanup the separate
fast and slow paths and remove the `enableShallowPropDiffing` flag which
we're not pursuing.
## How did you test this change?
```
yarn test ReactNativeAttributePayloadFabric
```
fixes https://github.com/facebook/react/issues/32449
This is my first time touching this code. There are multiple systems in
place here and I wouldn't be surprised to learn that this has to be
handled in some other areas too. I have found some other style-related
code areas but I had no time yet to double-check them.
cc @gnoff
