Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37381
SurfaceRegistry was a bridgeless-only concept, which hasn't actually diverged much from AppRegistry and doesn't support any new use-cases. It also causes additional complexity in terms of Logbox. Merge the logic with AppRegistry, and rewrite existing callers to AppRegistry.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D45730959
fbshipit-source-id: e2e2626c4dec8423aa097eff76cfa4d199f3a680
Summary:
## Summary
Initially reported in https://github.com/facebook/react/issues/26797.
Was not able to reproduce the exact same problem, but found this case:
1. Open corresponding codepen from the issue in debug mode
2. Open components tab of the extension
3. Refresh the page
Received multiple errors:
- Warning in the Console tab: Invalid renderer id "2".
- Error in the Components tab: Uncaught Error: Cannot add node "3"
because a node with that id is already in the Store.
This problem has occurred after landing a fix in
https://github.com/facebook/react/pull/26779. Looks like Chrome is
keeping the injected scripts (the backend in this case) and we start
backend twice.
DiffTrain build for commit https://github.com/facebook/react/commit/67a05d03e38b9837e27c9fe0a673557e63ff03c5.
Reviewed By: javache
Differential Revision: D45815160
Pulled By: hoxyq
fbshipit-source-id: 99f3c45009b07a0fb89f0674ccfb24f170cdb29d
Summary:
For these values we're not using dynamic values. We can statically
compile in the values we're running.
DiffTrain build for commit https://github.com/facebook/react/commit/df12d7eac40c87bd5fdde0aa5a739bce9e7dce27.
Reviewed By: tyao1
Differential Revision: D45751304
Pulled By: kassens
fbshipit-source-id: d00e441ab75bf8fe038bb0e80eeb392421344657
Summary:
When I was renaming the next channel to canary, I updated the
`publish_preleases` workflow correctly, but I skipped over
`publish_preleases_nightly`. Oops.
DiffTrain build for commit https://github.com/facebook/react/commit/7cd98ef2bcbc10f164f778bade86a4daeb821011.
Reviewed By: mofeiZ
Differential Revision: D45720403
fbshipit-source-id: 13ab5d0d0af6cc899944507249b39b03adbcb994
Summary:
The idea is that the default `yarn test` command should be the one that
includes the most bleeding edge features, because during development you
probably want as many features enabled as possible.
That used to be `www-modern` but nowadays it's `experimental` because
we've landed a bunch of async actions stuff in experimental but it isn't
yet being tested at Meta.
So this switches the default to `experimental`.
DiffTrain build for commit https://github.com/facebook/react/commit/b5810163e913e8c95a7a0a6dee039bc102e3c987.
Reviewed By: mofeiZ
Differential Revision: D45719891
fbshipit-source-id: 7c820b8b546f1c90bb3d77993befde86e42d399b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37273
When using dynamic frameworks, we can't rely on Codegen to register all the components into the renderer. That's because, we would have to codegen a new target, which depends on ALL the 3rd party dependencies that expose a UI component.
The previous PR adds support for distributed automatic registration when components are loaded in memory.
However, not to slow down the adoption of the New Architecture, there could be apps that need to register a component that does not support the distributed approach yet. Thanks to this method, apps can register those components.
## Changelog:
[iOS][Added] - Added a mechanism to register components into the renderer from the user app.
Reviewed By: dmytrorykun
Differential Revision: D45605688
fbshipit-source-id: 3583913f2700be4d6cb33a862429486aca675acf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37305
### Stack
ARIA roles in React Native are implemented on top of `accessibilityRole`. This is lossy because there are many more ARIA roles than `accessibilityRole`. This is especially true for RN on desktop where `accessibilityRole` was designed around accessibility APIs only available on mobile.
This series of changes aims to change this implementation to instead pass the ARIA role to native, alongside any existing `accessibilityRole`. This gives the platform more control in exactly how to map an ARIA role to native behavior.
As an example, this would allow mapping any ARIA role to [`AutomationControlType`](https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.peers.automationcontroltype?view=windowsdesktop-7.0&viewFallbackFrom=dotnet-uwp-10.0) on Windows without needing to fork to add new options to `accessibilityRole`.
It also allows greater implementation flexibility for other platforms down the line, but for now, iOS and Android behave the same as before (though with their implementation living in native).
### Diff
This syncs the Fabric representations of Roles to the current state of the world in JS, and adds usage to the view configs.
1. `Role` enum for the View `role` prop (ARIA role)
2. Sync enums and conversions to JS `AccessibilityRole`
1. This parsing is done for `TextAttributes` only. `View` uses the string directly
2. Add ARIA roles, and parse those to their enum form.
3. Move enums from attributedstring primitves to accessibility primitives
3. Add to viewconfig to allow it to be passed
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D45431372
fbshipit-source-id: 0150538345bbb6cb4d9426c4eebd0f67c2a33f3d
Summary:
Just a small upgrade to keep us current and remove unused suppressions
(probably fixed by some upgrade since).
- `*` is no longer allowed and has been an alias for `any` for a while
now.
DiffTrain build for commit https://github.com/facebook/react/commit/fda1f0b902b527089fe5ae7b3aa573c633166ec9.
Changelog: [Internal]
Reviewed By: tyao1
Differential Revision: D45695294
Pulled By: kassens
fbshipit-source-id: 1090328c30faf5ca8c22744f0b25ddf7fa60cd93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37337
Changelog: [Internal]
Removes usage of a local `Performance` instance, since this the global one is now safe to use.
Reviewed By: christophpurrer
Differential Revision: D45697243
fbshipit-source-id: 4f3f9798e79c15295094d5a4650af04db2856f60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37275
When enabling `USE_FRAMEWORKS=dynamic`, we need to explicitly defines all the dependencies used by the pods.
This change add those missing dependencies.
## Changelog:
[iOS][Added] - Add explicit dependencies for 3rd parties libraries
Reviewed By: NickGerleman
Differential Revision: D45523646
fbshipit-source-id: 228a7e0ae98ea262af4d58b7dc855f944ebed463
Summary:
FlatList `viewabilityConfig` prop seems no need to be any type. So I replaced it with `ViewabilityConfig` from `VirtualizedList.d.ts`
## Changelog:
[GENERAL] [FIXED] - change FlatList `viewabilityConfig` prop type `any` to `ViewabilityConfig`
Pull Request resolved: https://github.com/facebook/react-native/pull/37299
Test Plan: Ran yarn test-typescript and yarn test-typescript-offline with no errors.
Reviewed By: jacdebug
Differential Revision: D45689033
Pulled By: cipolleschi
fbshipit-source-id: e7fd31c534c5f47321b36d0d764f466392ad897e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37314
Turns out we never transitioned fbsource to an API change we made for FlatList, due to mismatched `.js` and `.js.flow` files.
Inside of RN, `$ArrayLike` in Flow, unlike `ArrayLike` in TypeScript, treats `length` as writable. So we wrap that in `$ReadOnly`. Another option might be to inline our own version, since it is not the only [case where they differ](https://fb.workplace.com/groups/flow/permalink/24328911383397481/).
In product code, the changes end up impacting:
1. `getItemLayout` is no longer typed to receive a mutable array. I changed all of the incompatible explicit type parameters from `Array<ItemT>` to `Iterable<ItemT>`.
2. Flow has a harder time inferring destructured `data` in examples that were passing `any` to FlatList, so I needed to give some type hints where `data` was previously untyped
3. Replace some `$FlowFixMe[incompatible-type]` with `$FlowFixMe[incompatible-type-arg]`
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D45665199
fbshipit-source-id: 59aa908e277a27f7ca88acb48de493d2782517a9
Summary:
- The whole project root is included by default anyway, the include
section should be redundant and just misleading.
- The generated ignore paths ignore more than intended as they didn't
escape the `.` for regex.
Changelog: [Internal]
Reviewed By: mofeiZ
Differential Revision: D45658874
Pulled By: kassens
fbshipit-source-id: fd1ec59eeffa3ac1cb39c190e17f018951fafbe7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37307
This should no longer log to `console.error()` after the latest prop-types update.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D45654389
fbshipit-source-id: c3d04c6a74b335e300137aa67bd7fb3640ba0303
Summary:
## Summary
We have a case:
1. Open components tab
2. Close Chrome / Firefox devtools window completely
3. Reopen browser devtools panel
4. Open components tab
Currently, in version 4.27.6, we cannot load the components tree.
This PR contains two changes:
- non-functional refactoring in
`react-devtools-shared/src/devtools/store.js`: removed some redundant
type castings.
- fixed backend manager logic (introduced in
https://github.com/facebook/react/pull/26615) to activate already
registered backends. Looks like frontend of devtools also depends on
`renderer-attached` event, without it component tree won't load.
## How did you test this change?
This fixes the case mentioned prior. Currently in 4.27.6 version it is
not working, we need to refresh the page to make it work.
I've tested this in several environments: chrome, firefox, standalone
with RN application.
DiffTrain build for commit https://github.com/facebook/react/commit/377c5175f78e47a3f01d323ad6528a696c88b76e.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45573294
Pulled By: tyao1
fbshipit-source-id: 42a8e4a54cd367080fdb7e1c357c48ae3564b7f0
Summary:
This automatically exposes `$$FORM_ACTIONS` on Server References coming
from Flight. So that when they're used in a form action, we can encode
the ID for the server reference as a hidden field or as part of the name
of a button.
If the Server Action is a bound function it can have complex data
associated with it. In this case this additional data is encoded as
additional form fields.
To process a POST on the server there's now a `decodeAction` helper that
can take one of these progressive posts from FormData and give you a
function that is prebound with the correct closure and FormData so that
you can just invoke it.
I updated the fixture which now has a "Server State" that gets
automatically refreshed. This also lets us visualize form fields.
There's no "Action State" here for showing error messages that are not
thrown, that's still up to user space.
DiffTrain build for commit https://github.com/facebook/react/commit/aef7ce5547c9489dc48e31f69b002cd17206e0cb.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: christophpurrer
Differential Revision: D45548613
Pulled By: tyao1
fbshipit-source-id: 0d4206c18c4818fa410e8b18f3a0f0942237c91b
Summary:
E.g. if we suspend (throw a promise) in pushStartInstance today we might
have already pushed some chunks (or even child segments potentially). We
should revert back to where we were.
This doesn't usually happen because when we suspend in a component it
doesn't write anything itself, it'll always defer to som host instance
to do the writing.
There was a todo about this already but I'm not 100% sure it's always
safe when suspending. It should be safe when suspending just regularly
because it's just a noop. We might not even want "throwing a promise" in
this mechanism to be supported longer term but for now that's how a
suspend in internals.
DiffTrain build for commit https://github.com/facebook/react/commit/c10010a6a00911fe99452bc561dd47c3e15f4eb8.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: christophpurrer
Differential Revision: D45547661
Pulled By: tyao1
fbshipit-source-id: 69654c95f06bc0f056fc8231e41aa395931af228
Summary:
Usually we don't have to do this since we only set these in the loop but
the ReactCustomFormAction props are optional so they might be undefined.
Also moved it to a general type since it's a semi-public API.
DiffTrain build for commit https://github.com/facebook/react/commit/fa7a447b9ce5a4f0be592fc2946380b0fa3b29c0.
Changelog: [Internal]:
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45537647
Pulled By: tyao1
fbshipit-source-id: 15aa00347467e424e3fa7d509139b2f87cdcdb69
Summary:
Drop the "state". Just "useOptimistic". It's cleaner.
This is still an experimental API. May not be the final name.
DiffTrain build for commit https://github.com/facebook/react/commit/b7972822b5887d05ae772ef757a453265b4b7aec.
Changelog: [Internal]:
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45537245
Pulled By: tyao1
fbshipit-source-id: e31f77c4a55e8931c9671d13fc43d6ff32e25dbb
Summary:
Forgot this allowlist existed. It's an extra safeguard, in case we mess
up the configuration somehow.
DiffTrain build for commit https://github.com/facebook/react/commit/388686f291afb2362fdc813c49f75b4132bc1314.
Changelog: [Internal]:
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45532426
Pulled By: tyao1
fbshipit-source-id: e81a2efe340bfa1f8397c5b1301956a0e94e5357
Summary:
## Summary
Fixes#26756.
DevTools is failing to inject `__REACT_DEVTOOLS_GLOBAL_HOOK__` hook in
incognito mode. This is not happening straight-forward, but if extension
is toggled on and off, the next time I try to open it I am receiving an
error that content script was already registered.
<img width="676" alt="Screenshot 2023-05-02 at 14 36 53"
src="https://user-images.githubusercontent.com/28902667/235877692-51c5d284-79d9-4b00-b62e-d25d5bb5e056.png">
- Unregistering content scripts before attempting to register them
again. We need to inject `__REACT_DEVTOOLS_GLOBAL_HOOK__` on each page,
so this should be expected behaviour.
- Fixed error logging
## How did you test this change?
Local build of extension for Chrome, trying the same steps, which
resulted in an error.
No regression in performance, tested on react.dev, still the same.
DiffTrain build for commit https://github.com/facebook/react/commit/8a25302c668d6f9a24f6680fb4947e9b388bb7d9.
Changelog: [Internal]:
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45532160
Pulled By: tyao1
fbshipit-source-id: d021721a4aee3e052512006f61cfdf72df56dbda
Summary:
The "next" prerelease channel represents what will be published the next
time we do a stable release. We publish a new "next" release every day
using a timed CI workflow.
When we introduced this prerelease channel a few years ago, another name
we considered was "canary". But I proposed "next" instead to create a
greater distinction between this channel and the "experimental" channel
(which is published at the same cadence, but includes extra experimental
features), because some other projects use "canary" to refer to releases
that are more unstable than how we would use it.
The main downside of "next" is someone might mistakenly assume the name
refers to Next.js. We were aware of this risk at the time but didn't
think it would be an issue in practice.
However, colloquially, we've ended up referring to this as the "canary"
channel anyway to avoid precisely that confusion.
So after further discussion, we've agreed to rename to "canary".
This affects the label used in the version string (e.g.
`18.3.0-next-a1c2d3e4` becomes `18.3.0-canary-a1c2d3e4`) as well as the
npm dist tags used to publish the releases. For now, I've chosen to
publish the canaries using both `canary` and `next` dist tags, so that
downstream consumers who might depend on `next` have time to adjust. We
can remove that later after the change has been communicated.
DiffTrain build for commit https://github.com/facebook/react/commit/2c2476834a7c739ca239750b73f74aa1df144a93.
Changelog: [Internal]:
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45531681
Pulled By: tyao1
fbshipit-source-id: 27ebe14eabad5c92fe6e5aa4944ff798b808ec33
Summary:
This key was only valid during the 2.0 beta period so we can remove it.
DiffTrain build for commit https://github.com/facebook/react/commit/fa4314841e7fdeef6e6bc5a7722fe74dc8e9fd89.
Changelog: [Internal]:
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45531656
Pulled By: tyao1
fbshipit-source-id: e2e3c9e5463c39e301361e18364d22dcec428c8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37264
Instead of disabling one test at a time, I've suppressed all the measure* related tests on Windows
with the hope to make the Windows CI less flaky.
Changelog:
[Internal] [Changed] - Disable all the measure* tests on Windows as they're flaky
Reviewed By: cipolleschi
Differential Revision: D45601448
fbshipit-source-id: 010905e1dbebd9c9da9d6710ea6ca0b99c4a2d5f
Summary:
Changelog: [Internal] - Noticed when I was cutting 0.72 types there was some types not exported and also some duplicate.
I'm not sure why our lint didn't catch this, I can look into that next
bypass-github-export-checks
Reviewed By: NickGerleman
Differential Revision: D45294027
fbshipit-source-id: addf5a5d7af10e3087edaaf660ff99e46932bc3e
Summary:
Stacked on top of #26735.
This allows a framework to add a `$$FORM_ACTION` property to a function.
This lets the framework return a set of props to use in place of the
function but only during SSR. Effectively, this lets you implement
progressive enhancement of form actions using some other way instead of
relying on the replay feature.
This will be used by RSC on Server References automatically by
convention in a follow up, but this mechanism can also be used by other
frameworks/libraries.
DiffTrain build for commit https://github.com/facebook/react/commit/559e83aebb2026035d47aa0ebf842f78d4cd6757.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45454355
Pulled By: tyao1
fbshipit-source-id: 4b4b65c77ecbc113a79e51e4aff97b2e3b88c31a
Summary:
This allows us to emit extra ephemeral data that will only be used on
server rendered forms.
First I refactored the shouldSkip functions to now just do that work
inside the canHydrate methods. This makes the Config bindings a little
less surface area but it also helps us optimize a bit since we now can
look at the code together and find shared paths.
canHydrate returns the instance if it matches, that used to just be
there to refine the type but it can also be used to just return a
different instance later that we find. If we don't find one, we'll bail
out and error regardless so no need to skip past anything.
DiffTrain build for commit https://github.com/facebook/react/commit/67f4fb02130b1fe1856289e3b66bb0b8cca57ff7.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45453502
Pulled By: tyao1
fbshipit-source-id: 1ac34bcc2d59fdbfbc25e51f6bd5354777a33f96
Summary:
in https://github.com/facebook/react/pull/26738 we added nonce to the
ResponseState. Initially it was used in a variety of places but the
version that got merged only included it with the external fizz runtime.
This PR updates the config for the external fizz runtime so that the
nonce is encoded into the script chunks at request creation time.
The rationale is that for live-requests, streaming is more likely than
not so doing the encoding work at the start is better than during flush.
For cases such as SSG where the runtime is not required the extra
encoding is tolerable (not a live request). Bots are an interesting case
because if you want fastest TTFB you will end up requiring the runtime
but if you are withholding until the stream is done you have already
sacrificed fastest TTFB and the marginal slowdown of the extraneous
encoding is hopefully neglibible
I'm writing this so later if we learn that this tradeoff isn't worth it
we at least understand why I made the change in the first place.
DiffTrain build for commit https://github.com/facebook/react/commit/8ea96ef84d8f08ed1846dec9e8ed20d2225db0d3.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45449587
Pulled By: tyao1
fbshipit-source-id: 76a5f34e42db5e9ad5a78b4b8f0d4e3dad2e7fcd
Summary:
This adds an experimental hook tentatively called useOptimisticState.
(The actual name needs some bikeshedding.)
The headline feature is that you can use it to implement optimistic
updates. If you set some optimistic state during a transition/action,
the state will be automatically reverted once the transition completes.
Another feature is that the optimistic updates will be continually
rebased on top of the latest state.
It's easiest to explain with examples; we'll publish documentation as
the API gets closer to stabilizing. See tests for now.
Technically the use cases for this hook are broader than just optimistic
updates; you could use it implement any sort of "pending" state, such as
the ones exposed by useTransition and useFormStatus. But we expect
people will most often reach for this hook to implement the optimistic
update pattern; simpler cases are covered by those other hooks.
DiffTrain build for commit https://github.com/facebook/react/commit/491aec5d6113ce5bae7c10966bc38a4a8fc091a8.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45448404
Pulled By: tyao1
fbshipit-source-id: 09b1e8c77fb6fb5d9f0859a2392234371c011b4f
Summary:
Adds support for nonce on `bootstrapScripts`, `bootstrapModules` and the external fizz runtime
DiffTrain build for commit https://github.com/facebook/react/commit/9545e4810c2dc8922f575b6d8f726503a7345d0c.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45446494
Pulled By: tyao1
fbshipit-source-id: 31a32a1b99bdc86069b06e0870009a9846a12085
Summary:
This test started failing recently in older versions of React because
the Scheduler priority inside a microtask is Normal instead of
Immediate. This is expected because microtasks are not Scheduler tasks;
it's an implementation detail.
I gated the test to only run in v17 because it's a regression test for
legacy Suspense behavior, and the implementation details of the snapshot
changed in v18.
Test plan
x---------
Using latest:
```
yarn test --build --project devtools --release-channel=experimental profilingcache
```
Using v17 (typically runs in a timed CI workflow):
```
/scripts/circleci/download_devtools_regression_build.js 17.0 --replaceBuild
yarn test --build --project devtools --release-channel=experimental --reactVersion 17.0 profilingcache
```
DiffTrain build for commit https://github.com/facebook/react/commit/86b0e91998a04b22bb54a95d54f4a7632efa902f.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45424707
fbshipit-source-id: f3a761984c0ac53b5514f8ff51635bf6c4bab8f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37216
Yet another windows flaky test for ReactFabricPublicInstance-test.js which I'm disabling now. It will still run on linux/mac.
Changelog:
[Internal] [Changed] - Disable flaky windows test for ReactFabricPublicInstance-test.js
Reviewed By: cipolleschi
Differential Revision: D45521018
fbshipit-source-id: b37c00d674997e14fd8e12c3f3746f51bcc90669
Summary:
Currently there is no way to provide a nonce when using
`ReactDOM.preinit(..., { as: 'script' })`
This PR adds `nonce?: string` as an option
While implementing this PR I added a test to also show you can pass
`integrity`. This test isn't directly related to the nonce change.
DiffTrain build for commit https://github.com/facebook/react/commit/b12bea62d9cfd9a925f28cb2c93daeda3865a64e.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45416244
Pulled By: tyao1
fbshipit-source-id: f92d66a1d6358c21e52a3b8003d06c662e2fc9fa
Summary:
This fixes a bug with `use` where if you update a component that's
currently suspended, React will sometimes mistake it for a render phase
update.
This happens because we don't reset `currentlyRenderingFiber` until the
suspended is unwound. And with `use`, that can happen asynchronously,
most commonly when the work loop is suspended during a transition.
The fix is to make sure `currentlyRenderingFiber` is only set when we're
in the middle of rendering, which used to be true until `use` was
introduced.
More specifically this means clearing `currentlyRenderingFiber` when
something throws and setting it again when we resume work.
In many cases, this bug will fail "gracefully" because the update is
still added to the queue; it's not dropped completely. It's also
somewhat rare because it has to be the exact same component that's
currently suspended. But it's still a bug. I wrote a regression test
that shows a sync update failing to interrupt a suspended component.
DiffTrain build for commit https://github.com/facebook/react/commit/18282f881dae106ebf6240aa52c8c02fe7c8d6f2.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: poteto
Differential Revision: D45407314
Pulled By: tyao1
fbshipit-source-id: 1303940cc34db28087563c20a187779a51d133de
Summary:
This hook reads the status of its ancestor form component, if it exists.
```js
const {pending, data, action, method} = useFormStatus();
```
It can be used to implement a loading indicator, for example. You can
think of it as a shortcut for implementing a loading state with the
useTransition hook.
For now, it's only available in the experimental channel. We'll share
docs once its closer to being stable. There are additional APIs that
will ship alongside it.
Internally it's implemented using startTransition + a context object.
That's a good way to think about its behavior, but the actual
implementation details may change in the future.
Because form elements cannot be nested, the implementation in the
reconciler does not bother to keep track of multiple nested "transition
providers". So although it's implemented using generic Fiber config
methods, it does currently make some assumptions based on React DOM's
requirements.
DiffTrain build for commit https://github.com/facebook/react/commit/540bab085d571789f4562565eebfd0db9f36345c.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: poteto
Differential Revision: D45332971
Pulled By: tyao1
fbshipit-source-id: 12e2b5a6c71fc78efb8aedfd1907f65a816cc289
Summary:
When there are multiple async actions at the same time, we entangle them
together because we can't be sure which action an update might be
associated with. (For this, we'd need AsyncContext.) However, if one of
the async actions fails with an error, it should only affect that
action, not all the other actions it may be entangled with.
Resolving each action independently also means they can have independent
pending state types, rather than being limited to an `isPending`
boolean. We'll use this to implement an upcoming form API.
DiffTrain build for commit https://github.com/facebook/react/commit/6eadbe0c4aebf68410bb48147054ee22eec4c20c.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: poteto
Differential Revision: D45301261
Pulled By: tyao1
fbshipit-source-id: e571d306be12f184c98ad7c24ff1ec1dbf788056
Sam Zhou
Pieter De Baets
Philip Heinser
javache (Meta Employee)
hoxyq (Meta Employee)
kassens (Meta Employee)
acdlite
Riccardo Cipolleschi
Nick Gerleman
Pieter Vanderwerff
Luna Wei
Ruslan Shestopalyuk
Jerry
gaearon (Meta Employee)
sammy-SC (Meta Employee)andDan Abramov
sebmarkbage
Nicola Corti
gnoff
eps1lon
