Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force unwind work loop during selective hydration #25695

Merged
merged 1 commit into from
Nov 17, 2022

Conversation

acdlite
Copy link
Collaborator

@acdlite acdlite commented Nov 16, 2022

When an update flows into a dehydrated boundary, React cannot apply the update until the boundary has finished hydrating. The way this currently works is by scheduling a slightly higher priority task on the boundary, using a special lane that's reserved only for this purpose. Because the task is slightly higher priority, on the next turn of the work loop, the Scheduler will force the work loop to yield (i.e. shouldYield starts returning true because there's a higher priority task).

The downside of this approach is that it only works when time slicing is enabled. It doesn't work for synchronous updates, because the synchronous work loop does not consult the Scheduler on each iteration.

We plan to add support for selective hydration during synchronous updates, too, so we need to model this some other way.

I've added a special internal exception that can be thrown to force the work loop to interrupt the work-in-progress tree. Because it's thrown from a React-only execution stack, throwing isn't strictly necessary — we could instead modify some internal work loop state. But using an exception means we don't need to check for this case on every iteration of the work loop. So doing it this way moves the check out of the fast path.

The ideal implementation wouldn't need to unwind the stack at all — we should be able to hydrate the subtree and then apply the update all within a single render phase. This is how we intend to implement it in the future, but this requires a refactor to how we handle "stack" variables, which are currently pushed to a per-render array. We need to make this stack resumable, like how context works in Flight and Fizz.

@facebook-github-bot facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Nov 16, 2022
@sizebot
Copy link

sizebot commented Nov 16, 2022

Comparing: 7b17f7b...e86bb50

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name +/- Base Current +/- gzip Base gzip Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js +0.08% 153.62 kB 153.75 kB +0.08% 48.83 kB 48.87 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js +0.08% 155.55 kB 155.67 kB +0.04% 49.47 kB 49.49 kB
facebook-www/ReactDOM-prod.classic.js +0.12% 530.40 kB 531.04 kB +0.07% 94.15 kB 94.21 kB
facebook-www/ReactDOM-prod.modern.js +0.12% 515.66 kB 516.29 kB +0.07% 91.96 kB 92.02 kB
facebook-www/ReactDOMForked-prod.classic.js +0.12% 530.40 kB 531.04 kB +0.07% 94.15 kB 94.21 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show
Name +/- Base Current +/- gzip Base gzip Current gzip
oss-stable-semver/react-test-renderer/cjs/react-test-renderer.development.js +0.36% 743.91 kB 746.57 kB +0.40% 160.77 kB 161.40 kB
oss-stable/react-test-renderer/cjs/react-test-renderer.development.js +0.36% 743.94 kB 746.59 kB +0.40% 160.79 kB 161.43 kB
oss-experimental/react-test-renderer/cjs/react-test-renderer.development.js +0.36% 744.04 kB 746.70 kB +0.40% 160.82 kB 161.46 kB
oss-stable-semver/react-test-renderer/umd/react-test-renderer.development.js +0.35% 779.30 kB 782.07 kB +0.39% 162.46 kB 163.10 kB
oss-stable/react-test-renderer/umd/react-test-renderer.development.js +0.35% 779.33 kB 782.09 kB +0.39% 162.49 kB 163.12 kB
oss-experimental/react-test-renderer/umd/react-test-renderer.development.js +0.35% 779.43 kB 782.19 kB +0.39% 162.52 kB 163.16 kB
oss-stable-semver/react-art/cjs/react-art.development.js +0.35% 764.48 kB 767.14 kB +0.38% 164.87 kB 165.50 kB
oss-stable/react-art/cjs/react-art.development.js +0.35% 764.51 kB 767.17 kB +0.38% 164.90 kB 165.53 kB
oss-experimental/react-art/cjs/react-art.development.js +0.34% 772.31 kB 774.97 kB +0.38% 166.31 kB 166.95 kB
facebook-react-native/react-test-renderer/cjs/ReactTestRenderer-dev.js +0.34% 758.22 kB 760.81 kB +0.39% 162.37 kB 163.00 kB
facebook-www/ReactTestRenderer-dev.modern.js +0.33% 774.62 kB 777.21 kB +0.39% 165.61 kB 166.26 kB
facebook-www/ReactTestRenderer-dev.classic.js +0.33% 774.62 kB 777.21 kB +0.39% 165.61 kB 166.26 kB
oss-stable-semver/react-art/umd/react-art.development.js +0.32% 871.63 kB 874.40 kB +0.35% 183.09 kB 183.74 kB
oss-stable/react-art/umd/react-art.development.js +0.32% 871.66 kB 874.42 kB +0.35% 183.11 kB 183.76 kB
oss-stable-semver/react-reconciler/cjs/react-reconciler.development.js +0.31% 844.14 kB 846.80 kB +0.38% 179.13 kB 179.81 kB
oss-stable/react-reconciler/cjs/react-reconciler.development.js +0.31% 844.17 kB 846.82 kB +0.38% 179.15 kB 179.83 kB
oss-experimental/react-art/umd/react-art.development.js +0.31% 879.90 kB 882.67 kB +0.35% 184.51 kB 185.15 kB
oss-experimental/react-reconciler/cjs/react-reconciler.development.js +0.31% 851.97 kB 854.63 kB +0.36% 180.59 kB 181.25 kB
react-native/implementations/ReactFabric-dev.js +0.31% 836.84 kB 839.43 kB +0.35% 181.32 kB 181.96 kB
react-native/implementations/ReactNativeRenderer-dev.js +0.31% 846.38 kB 848.97 kB +0.34% 183.76 kB 184.40 kB
facebook-www/ReactART-dev.modern.js +0.30% 865.43 kB 868.02 kB +0.37% 182.54 kB 183.21 kB
react-native/implementations/ReactFabric-dev.fb.js +0.30% 873.57 kB 876.16 kB +0.34% 188.48 kB 189.13 kB
facebook-www/ReactART-dev.classic.js +0.30% 875.74 kB 878.33 kB +0.36% 184.63 kB 185.29 kB
react-native/implementations/ReactNativeRenderer-dev.fb.js +0.29% 883.09 kB 885.68 kB +0.34% 190.96 kB 191.61 kB
oss-stable-semver/react-test-renderer/cjs/react-test-renderer.production.min.js +0.29% 99.24 kB 99.52 kB +0.27% 30.50 kB 30.58 kB
oss-stable/react-test-renderer/cjs/react-test-renderer.production.min.js +0.29% 99.26 kB 99.55 kB +0.29% 30.50 kB 30.59 kB
oss-experimental/react-test-renderer/cjs/react-test-renderer.production.min.js +0.29% 99.32 kB 99.61 kB +0.29% 30.53 kB 30.62 kB
oss-stable-semver/react-test-renderer/umd/react-test-renderer.production.min.js +0.29% 99.49 kB 99.77 kB +0.22% 30.93 kB 30.99 kB
oss-stable/react-test-renderer/umd/react-test-renderer.production.min.js +0.29% 99.51 kB 99.80 kB +0.23% 30.92 kB 31.00 kB
oss-experimental/react-test-renderer/umd/react-test-renderer.production.min.js +0.29% 99.57 kB 99.86 kB +0.22% 30.95 kB 31.02 kB
facebook-react-native/react-test-renderer/cjs/ReactTestRenderer-prod.js +0.27% 286.77 kB 287.54 kB +0.28% 50.58 kB 50.72 kB
facebook-react-native/react-test-renderer/cjs/ReactTestRenderer-profiling.js +0.25% 302.38 kB 303.15 kB +0.26% 52.93 kB 53.06 kB
react-native/implementations/ReactFabric-prod.js +0.24% 314.09 kB 314.85 kB +0.24% 55.54 kB 55.67 kB
react-native/implementations/ReactNativeRenderer-prod.js +0.24% 320.24 kB 321.00 kB +0.21% 56.49 kB 56.61 kB
react-native/implementations/ReactFabric-prod.fb.js +0.24% 324.83 kB 325.59 kB +0.23% 57.68 kB 57.81 kB
react-native/implementations/ReactFabric-profiling.js +0.23% 333.29 kB 334.06 kB +0.19% 58.74 kB 58.86 kB
react-native/implementations/ReactNativeRenderer-prod.fb.js +0.23% 330.98 kB 331.74 kB +0.24% 58.65 kB 58.79 kB
react-native/implementations/ReactNativeRenderer-profiling.js +0.23% 339.52 kB 340.30 kB +0.21% 59.71 kB 59.84 kB
oss-stable-semver/react-dom/cjs/react-dom.development.js +0.22% 1,194.04 kB 1,196.69 kB +0.25% 264.79 kB 265.47 kB
oss-stable/react-dom/cjs/react-dom.development.js +0.22% 1,194.06 kB 1,196.72 kB +0.25% 264.82 kB 265.49 kB
oss-experimental/react-dom/cjs/react-dom-unstable_testing.development.js +0.22% 1,197.01 kB 1,199.67 kB +0.25% 265.30 kB 265.97 kB
react-native/implementations/ReactFabric-profiling.fb.js +0.22% 351.63 kB 352.41 kB +0.21% 61.78 kB 61.91 kB
oss-stable-semver/react-dom/umd/react-dom.development.js +0.22% 1,252.08 kB 1,254.84 kB +0.25% 267.68 kB 268.35 kB
oss-stable/react-dom/umd/react-dom.development.js +0.22% 1,252.10 kB 1,254.87 kB +0.25% 267.70 kB 268.37 kB
oss-experimental/react-dom/cjs/react-dom.development.js +0.22% 1,204.11 kB 1,206.77 kB +0.24% 266.83 kB 267.46 kB
oss-experimental/react-dom/umd/react-dom.development.js +0.22% 1,262.70 kB 1,265.47 kB +0.25% 269.65 kB 270.31 kB
react-native/implementations/ReactNativeRenderer-profiling.fb.js +0.22% 357.84 kB 358.62 kB +0.19% 62.85 kB 62.96 kB
facebook-www/ReactDOMTesting-dev.modern.js +0.22% 1,197.77 kB 1,200.36 kB +0.24% 265.04 kB 265.69 kB
facebook-www/ReactDOMTesting-dev.classic.js +0.21% 1,227.64 kB 1,230.24 kB +0.24% 270.80 kB 271.44 kB

Generated by 🚫 dangerJS against e86bb50

@acdlite acdlite marked this pull request as ready for review November 16, 2022 18:23
@acdlite acdlite requested review from tyao1 and sebmarkbage November 16, 2022 18:23
// work loop state. But using an exception means we don't need to
// check for this case on every iteration of the work loop. So doing
// it this way moves the check out of the fast path.
throw SelectiveHydrationException;
} else {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this branch just a bug in React? Not sure how it happens exactly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same answer as here: cd34ec3#r1024411227

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This link is broken.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It happens when the hydration lane is suspended. That indicates we already attempted to hydrate but we couldn't because the code/data isn't ready. In that case we switch back to the original update lane and render without hydrating. Without this branch it would keep restarting in a loop until the data resolved.

// we yield. TODO: We could probably just force yielding earlier instead.
// we yield.
// TODO: This should only happen for sync updates, which don't have a
// hydration lane. We should add one. Then, consider removing this call.
renderDidSuspendDelayIfPossible();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this call just unnecessary now? This flag doesn't do anything in sync mode anyway?

@@ -2808,7 +2826,9 @@ function updateDehydratedSuspenseComponent(

// If we have scheduled higher pri work above, this will just abort the render
// since we now have higher priority work. We'll try to infinitely suspend until
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment doesn't really make sense if this only happens for sync.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the explanation is wrong. It's because if hydration suspends, we go back to the original update lane and switch to a client render. Then we suspend with delay.

@tyao1 tyao1 mentioned this pull request Nov 16, 2022
When an update flows into a dehydrated boundary, React cannot apply the
update until the boundary has finished hydrating. The way this currently
works is by scheduling a slightly higher priority task on the boundary,
using a special lane that's reserved only for this purpose. Because
the task is slightly higher priority, on the next turn of the work loop,
the Scheduler will force the work loop to yield (i.e. shouldYield starts
returning `true` because there's a higher priority task).

The downside of this approach is that it only works when time slicing
is enabled. It doesn't work for synchronous updates, because the
synchronous work loop does not consult the Scheduler on each iteration.

We plan to add support for selective hydration during synchronous
updates, too, so we need to model this some other way.

I've added a special internal exception that can be thrown to force the
work loop to interrupt the work-in-progress tree. Because it's thrown
from a React-only execution stack, throwing isn't strictly necessary —
we could instead modify some internal work loop state. But using an
exception means we don't need to check for this case on every iteration
of the work loop. So doing it this way moves the check out of the
fast path.

The ideal implementation wouldn't need to unwind the stack at all — we
should be able to hydrate the subtree and then apply the update all 
within a single render phase. This is how we intend to implement it in
the future, but this requires a refactor to how we handle "stack"
variables, which are currently pushed to a per-render array. We need to
make this stack resumable, like how context works in Flight and Fizz.
@acdlite acdlite force-pushed the force-unwind-selective-hydration branch from cd34ec3 to e86bb50 Compare November 17, 2022 18:33
@acdlite acdlite merged commit 44c4e6f into facebook:main Nov 17, 2022
tyao1 added a commit that referenced this pull request Nov 17, 2022
<!--
  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 debug-test --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

<!--
Explain the **motivation** for making this change. What existing problem
does the pull request solve?
-->
For more context: #25692

Based on #25695. This PR adds the
`SyncHydrationLane` so we rewind on sync updates during selective
hydration. Also added tests for ContinuouseHydration and
DefaultHydration lanes.


## 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.
-->
yarn test
rickhanlonii pushed a commit that referenced this pull request Dec 3, 2022
When an update flows into a dehydrated boundary, React cannot apply the
update until the boundary has finished hydrating. The way this currently
works is by scheduling a slightly higher priority task on the boundary,
using a special lane that's reserved only for this purpose. Because the
task is slightly higher priority, on the next turn of the work loop, the
Scheduler will force the work loop to yield (i.e. shouldYield starts
returning `true` because there's a higher priority task).

The downside of this approach is that it only works when time slicing is
enabled. It doesn't work for synchronous updates, because the
synchronous work loop does not consult the Scheduler on each iteration.

We plan to add support for selective hydration during synchronous
updates, too, so we need to model this some other way.

I've added a special internal exception that can be thrown to force the
work loop to interrupt the work-in-progress tree. Because it's thrown
from a React-only execution stack, throwing isn't strictly necessary —
we could instead modify some internal work loop state. But using an
exception means we don't need to check for this case on every iteration
of the work loop. So doing it this way moves the check out of the fast
path.

The ideal implementation wouldn't need to unwind the stack at all — we
should be able to hydrate the subtree and then apply the update all
within a single render phase. This is how we intend to implement it in
the future, but this requires a refactor to how we handle "stack"
variables, which are currently pushed to a per-render array. We need to
make this stack resumable, like how context works in Flight and Fizz.
acdlite added a commit to acdlite/react that referenced this pull request Dec 5, 2022
…5695)"

We're reverting the stack of changes that this code belongs to in order
to unblock the sync to Meta's internal codebase. We will attempt to
re-land once the sync is unblocked.
tyao1 added a commit that referenced this pull request Dec 5, 2022
tyao1 pushed a commit that referenced this pull request Dec 7, 2022
When an update flows into a dehydrated boundary, React cannot apply the
update until the boundary has finished hydrating. The way this currently
works is by scheduling a slightly higher priority task on the boundary,
using a special lane that's reserved only for this purpose. Because the
task is slightly higher priority, on the next turn of the work loop, the
Scheduler will force the work loop to yield (i.e. shouldYield starts
returning `true` because there's a higher priority task).

The downside of this approach is that it only works when time slicing is
enabled. It doesn't work for synchronous updates, because the
synchronous work loop does not consult the Scheduler on each iteration.

We plan to add support for selective hydration during synchronous
updates, too, so we need to model this some other way.

I've added a special internal exception that can be thrown to force the
work loop to interrupt the work-in-progress tree. Because it's thrown
from a React-only execution stack, throwing isn't strictly necessary —
we could instead modify some internal work loop state. But using an
exception means we don't need to check for this case on every iteration
of the work loop. So doing it this way moves the check out of the fast
path.

The ideal implementation wouldn't need to unwind the stack at all — we
should be able to hydrate the subtree and then apply the update all
within a single render phase. This is how we intend to implement it in
the future, but this requires a refactor to how we handle "stack"
variables, which are currently pushed to a per-render array. We need to
make this stack resumable, like how context works in Flight and Fizz.
tyao1 pushed a commit that referenced this pull request Dec 8, 2022
When an update flows into a dehydrated boundary, React cannot apply the
update until the boundary has finished hydrating. The way this currently
works is by scheduling a slightly higher priority task on the boundary,
using a special lane that's reserved only for this purpose. Because the
task is slightly higher priority, on the next turn of the work loop, the
Scheduler will force the work loop to yield (i.e. shouldYield starts
returning `true` because there's a higher priority task).

The downside of this approach is that it only works when time slicing is
enabled. It doesn't work for synchronous updates, because the
synchronous work loop does not consult the Scheduler on each iteration.

We plan to add support for selective hydration during synchronous
updates, too, so we need to model this some other way.

I've added a special internal exception that can be thrown to force the
work loop to interrupt the work-in-progress tree. Because it's thrown
from a React-only execution stack, throwing isn't strictly necessary —
we could instead modify some internal work loop state. But using an
exception means we don't need to check for this case on every iteration
of the work loop. So doing it this way moves the check out of the fast
path.

The ideal implementation wouldn't need to unwind the stack at all — we
should be able to hydrate the subtree and then apply the update all
within a single render phase. This is how we intend to implement it in
the future, but this requires a refactor to how we handle "stack"
variables, which are currently pushed to a per-render array. We need to
make this stack resumable, like how context works in Flight and Fizz.
tyao1 pushed a commit that referenced this pull request Dec 13, 2022
When an update flows into a dehydrated boundary, React cannot apply the
update until the boundary has finished hydrating. The way this currently
works is by scheduling a slightly higher priority task on the boundary,
using a special lane that's reserved only for this purpose. Because the
task is slightly higher priority, on the next turn of the work loop, the
Scheduler will force the work loop to yield (i.e. shouldYield starts
returning `true` because there's a higher priority task).

The downside of this approach is that it only works when time slicing is
enabled. It doesn't work for synchronous updates, because the
synchronous work loop does not consult the Scheduler on each iteration.

We plan to add support for selective hydration during synchronous
updates, too, so we need to model this some other way.

I've added a special internal exception that can be thrown to force the
work loop to interrupt the work-in-progress tree. Because it's thrown
from a React-only execution stack, throwing isn't strictly necessary —
we could instead modify some internal work loop state. But using an
exception means we don't need to check for this case on every iteration
of the work loop. So doing it this way moves the check out of the fast
path.

The ideal implementation wouldn't need to unwind the stack at all — we
should be able to hydrate the subtree and then apply the update all
within a single render phase. This is how we intend to implement it in
the future, but this requires a refactor to how we handle "stack"
variables, which are currently pushed to a per-render array. We need to
make this stack resumable, like how context works in Flight and Fizz.
tyao1 added a commit that referenced this pull request Dec 15, 2022
This PR includes the previously reverted #25695 and #25754, and the fix
for the regression test added in #25867.


Tested internally with a previous failed test,  and it's passing now.

Co-authored-by: Andrew Clark <git@andrewclark.io>
github-actions bot pushed a commit that referenced this pull request Dec 15, 2022
This PR includes the previously reverted #25695 and #25754, and the fix
for the regression test added in #25867.

Tested internally with a previous failed test,  and it's passing now.

Co-authored-by: Andrew Clark <git@andrewclark.io>

DiffTrain build for [7efa9e5](7efa9e5)
[View git log for this commit](https://github.com/facebook/react/commits/7efa9e59707b341f10fab79724e0fca373187925)
facebook-github-bot pushed a commit to facebook/react-native that referenced this pull request Jan 30, 2023
Summary:
Three problems popped up during the sync:
- facebook/react@07f46ecf2 breaks breaks tests
- facebook/react@6fb8133ed breaks fbsource tests. I added a workaround and created a test for the team that owns the test.
- https://fb.workplace.com/groups/flowlang/permalink/1198137807458547/ enables local type interference in fbsource but not in github React repo and some code breaks. Addressed in facebook/react#26064

This sync includes the following changes:
- **[17f6912a4](facebook/react@17f6912a4 )**: Add flow types to ReactFiberHooks ([#25752](facebook/react#25752)) //<Samuel Susla>//
- **[f101c2d0d](facebook/react@f101c2d0d )**: Remove Reconciler fork (2/2) ([#25775](facebook/react#25775)) //<Jan Kassens>//
- **[420f0b7fa](facebook/react@420f0b7fa )**: Remove Reconciler fork (1/2) ([#25774](facebook/react#25774)) //<Jan Kassens>//
- **[3ba7add60](facebook/react@3ba7add60 )**: Allow async blocks in `to(Error|Warn)Dev` ([#25338](facebook/react#25338)) //<Sebastian Silbermann>//
- **[fa11bd6ec](facebook/react@fa11bd6ec )**: [ServerRenderer] Add option to send instructions as data attributes ([#25437](facebook/react#25437)) //<mofeiZ>//
- **[e98225485](facebook/react@e98225485 )**: Add ref cleanup function ([#25686](facebook/react#25686)) //<Samuel Susla>//
- **[15557fa67](facebook/react@15557fa67 )**: [Fix] properly track `useId` use in StrictMode in development ([#25713](facebook/react#25713)) //<Josh Story>//
- **[8a23def32](facebook/react@8a23def32 )**: Resubmit Add HydrationSyncLane ([#25711](facebook/react#25711)) //<Tianyu Yao>//
- **[2655c9354](facebook/react@2655c9354 )**: Fizz Browser: fix precomputed chunk being cleared on Node 18 ([#25645](facebook/react#25645)) //<Jimmy Lai>//
- **[c08d8b804](facebook/react@c08d8b804 )**: Revert "Add SyncHydrationLane" ([#25708](facebook/react#25708)) //<Tianyu Yao>//
- **[56ffca8b9](facebook/react@56ffca8b9 )**: Add Bun streaming server renderer ([#25597](facebook/react#25597)) //<Colin McDonnell>//
- **[f31005d6a](facebook/react@f31005d6a )**: Add SyncHydrationLane ([#25698](facebook/react#25698)) //<Tianyu Yao>//
- **[f284d9faf](facebook/react@f284d9faf )**: Track ThenableState alongside other hooks //<Andrew Clark>//
- **[6b4c0314e](facebook/react@6b4c0314e )**: Check thenable instead of thenableState //<Andrew Clark>//
- **[33e3d2878](facebook/react@33e3d2878 )**: Reuse hooks when replaying a suspended component //<Andrew Clark>//
- **[4387d752d](facebook/react@4387d752d )**: Allow more hooks to be added when replaying mount //<Andrew Clark>//
- **[5eb78d0a0](facebook/react@5eb78d0a0 )**: Pass ThenableState to replaySuspendedUnitOfWork //<Andrew Clark>//
- **[4a2d86bdd](facebook/react@4a2d86bdd )**: Don't reset work loop until stack is unwound //<Andrew Clark>//
- **[9dfbd9fa9](facebook/react@9dfbd9fa9 )**: use: Don't suspend if there are pending updates //<Andrew Clark>//
- **[44c4e6f4d](facebook/react@44c4e6f4d )**: Force unwind work loop during selective hydration ([#25695](facebook/react#25695)) //<Andrew Clark>//
- **[7b17f7bbf](facebook/react@7b17f7bbf )**: Enable warning for defaultProps on function components for everyone ([#25699](facebook/react#25699)) //<Sebastian Markbåge>//
- **[6fb8133ed](facebook/react@6fb8133ed )**: Turn on string ref deprecation warning for everybody (not codemoddable) ([#25383](facebook/react#25383)) //<Sebastian Silbermann>//
- **[07f46ecf2](facebook/react@07f46ecf2 )**: Turn on key spread warning in jsx-runtime for everyone ([#25697](facebook/react#25697)) //<Sebastian Markbåge>//
- **[d65b88d03](facebook/react@d65b88d03 )**: Eagerly initialize an mutable object for instance.refs ([#25696](facebook/react#25696)) //<Sebastian Markbåge>//
- **[c343f8025](facebook/react@c343f8025 )**: [react-float] feature detect getRootNode ([#25689](facebook/react#25689)) //<Jan Kassens>//
- **[e1dd0a2f5](facebook/react@e1dd0a2f5 )**: Remove recoverable error when a sync update flows into a dehydrated boundary ([#25692](facebook/react#25692)) //<Sebastian Markbåge>//
- **[c54e3541b](facebook/react@c54e3541b )**: [DevTools] bug fix for Hydrating fibers ([#25663](facebook/react#25663)) //<Mengdi Chen>//

Changelog:
[General][Changed] - React Native sync for revisions d1e35c7...17f6912

jest_e2e[run_all_tests]

Reviewed By: makovkastar

Differential Revision: D42804802

fbshipit-source-id: 6a9f00724cc73378025bbd04edb2d17760a87280
OlimpiaZurek pushed a commit to OlimpiaZurek/react-native that referenced this pull request May 22, 2023
Summary:
Three problems popped up during the sync:
- facebook/react@07f46ecf2 breaks breaks tests
- facebook/react@6fb8133ed breaks fbsource tests. I added a workaround and created a test for the team that owns the test.
- https://fb.workplace.com/groups/flowlang/permalink/1198137807458547/ enables local type interference in fbsource but not in github React repo and some code breaks. Addressed in facebook/react#26064

This sync includes the following changes:
- **[17f6912a4](facebook/react@17f6912a4 )**: Add flow types to ReactFiberHooks ([facebook#25752](facebook/react#25752)) //<Samuel Susla>//
- **[f101c2d0d](facebook/react@f101c2d0d )**: Remove Reconciler fork (2/2) ([facebook#25775](facebook/react#25775)) //<Jan Kassens>//
- **[420f0b7fa](facebook/react@420f0b7fa )**: Remove Reconciler fork (1/2) ([facebook#25774](facebook/react#25774)) //<Jan Kassens>//
- **[3ba7add60](facebook/react@3ba7add60 )**: Allow async blocks in `to(Error|Warn)Dev` ([facebook#25338](facebook/react#25338)) //<Sebastian Silbermann>//
- **[fa11bd6ec](facebook/react@fa11bd6ec )**: [ServerRenderer] Add option to send instructions as data attributes ([facebook#25437](facebook/react#25437)) //<mofeiZ>//
- **[e98225485](facebook/react@e98225485 )**: Add ref cleanup function ([facebook#25686](facebook/react#25686)) //<Samuel Susla>//
- **[15557fa67](facebook/react@15557fa67 )**: [Fix] properly track `useId` use in StrictMode in development ([facebook#25713](facebook/react#25713)) //<Josh Story>//
- **[8a23def32](facebook/react@8a23def32 )**: Resubmit Add HydrationSyncLane ([facebook#25711](facebook/react#25711)) //<Tianyu Yao>//
- **[2655c9354](facebook/react@2655c9354 )**: Fizz Browser: fix precomputed chunk being cleared on Node 18 ([facebook#25645](facebook/react#25645)) //<Jimmy Lai>//
- **[c08d8b804](facebook/react@c08d8b804 )**: Revert "Add SyncHydrationLane" ([facebook#25708](facebook/react#25708)) //<Tianyu Yao>//
- **[56ffca8b9](facebook/react@56ffca8b9 )**: Add Bun streaming server renderer ([facebook#25597](facebook/react#25597)) //<Colin McDonnell>//
- **[f31005d6a](facebook/react@f31005d6a )**: Add SyncHydrationLane ([facebook#25698](facebook/react#25698)) //<Tianyu Yao>//
- **[f284d9faf](facebook/react@f284d9faf )**: Track ThenableState alongside other hooks //<Andrew Clark>//
- **[6b4c0314e](facebook/react@6b4c0314e )**: Check thenable instead of thenableState //<Andrew Clark>//
- **[33e3d2878](facebook/react@33e3d2878 )**: Reuse hooks when replaying a suspended component //<Andrew Clark>//
- **[4387d752d](facebook/react@4387d752d )**: Allow more hooks to be added when replaying mount //<Andrew Clark>//
- **[5eb78d0a0](facebook/react@5eb78d0a0 )**: Pass ThenableState to replaySuspendedUnitOfWork //<Andrew Clark>//
- **[4a2d86bdd](facebook/react@4a2d86bdd )**: Don't reset work loop until stack is unwound //<Andrew Clark>//
- **[9dfbd9fa9](facebook/react@9dfbd9fa9 )**: use: Don't suspend if there are pending updates //<Andrew Clark>//
- **[44c4e6f4d](facebook/react@44c4e6f4d )**: Force unwind work loop during selective hydration ([facebook#25695](facebook/react#25695)) //<Andrew Clark>//
- **[7b17f7bbf](facebook/react@7b17f7bbf )**: Enable warning for defaultProps on function components for everyone ([facebook#25699](facebook/react#25699)) //<Sebastian Markbåge>//
- **[6fb8133ed](facebook/react@6fb8133ed )**: Turn on string ref deprecation warning for everybody (not codemoddable) ([facebook#25383](facebook/react#25383)) //<Sebastian Silbermann>//
- **[07f46ecf2](facebook/react@07f46ecf2 )**: Turn on key spread warning in jsx-runtime for everyone ([facebook#25697](facebook/react#25697)) //<Sebastian Markbåge>//
- **[d65b88d03](facebook/react@d65b88d03 )**: Eagerly initialize an mutable object for instance.refs ([facebook#25696](facebook/react#25696)) //<Sebastian Markbåge>//
- **[c343f8025](facebook/react@c343f8025 )**: [react-float] feature detect getRootNode ([facebook#25689](facebook/react#25689)) //<Jan Kassens>//
- **[e1dd0a2f5](facebook/react@e1dd0a2f5 )**: Remove recoverable error when a sync update flows into a dehydrated boundary ([facebook#25692](facebook/react#25692)) //<Sebastian Markbåge>//
- **[c54e3541b](facebook/react@c54e3541b )**: [DevTools] bug fix for Hydrating fibers ([facebook#25663](facebook/react#25663)) //<Mengdi Chen>//

Changelog:
[General][Changed] - React Native sync for revisions d1e35c7...17f6912

jest_e2e[run_all_tests]

Reviewed By: makovkastar

Differential Revision: D42804802

fbshipit-source-id: 6a9f00724cc73378025bbd04edb2d17760a87280
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants