Summary:
Nightly builds of Android no longer build due to a recent version format change.
## Changelog:
[ANDROID] [FIXED] - Fixed nightly builds of Android no longer building due to a recent version format change
Pull Request resolved: https://github.com/facebook/react-native/pull/37332
Test Plan:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version nightly
cd example
yarn android
```
Reviewed By: jacdebug
Differential Revision: D45690926
Pulled By: cortinico
fbshipit-source-id: dc935733607c2b33ba296b507a98f43ba483e348
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/37276
When enabling dynamic linking, we had a circulr dependency between Fabric and the Image Manager.
Specifically, Image Manager depends on Fabric, but the Image component, in Fabric, is using some implementation specific files from the Image Manager that surface only when enabling the dynamic linking.
Xcode fails to find those symbols unless the dependencies are explicitly added to the podspec.
This change is technically breaking, but we tried to minimize the breakage by adding the new pod in all the required search paths.
## Changelog
[iOS][Breaking] - Add React-FabricImage pod.
Reviewed By: NickGerleman
Differential Revision: D45517278
fbshipit-source-id: 994aa8c40301c68bf9fecdf46de7833028f0d3c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37312
## Why?
Internally one of our apps is using a custom view manager that isn't respecting the `NotNull` constraint,
causing a runtime error. We have no visibility over what this manager is. The custom exception will give
us more clues to track this down.
If you look at the below stack trace, it's pretty clear the earlier approach would fail:
{F979121677}
Like a bit of a noddy, I've been waiting for days for the new exception to be hit, when it's very clear from [3 May](https://fburl.com/scuba/errorreporting_facebook_android_crashes/a63t7ilm) that this wasn't going to happen:
{F979130611}
The lesson here is to monitor 3 things:
1. the [original NullPointerExceptions](https://fburl.com/scuba/errorreporting_facebook_android_crashes/m2o0t45h),
2. the new [ReactViewReturnTypeException](https://fburl.com/scuba/errorreporting_facebook_android_crashes/2j0vtuwb), and
3. the [number of users exposed](https://fburl.com/scuba/mobile_active_users/9mbevwed) to whatever release this change goes out on.
Changelog: [Internal]
The NullPointerExceptions are hit when call the the java createView method. Previous (D45185598)
didn't capture this exception and wasn't very useful.
Reviewed By: cortinico
Differential Revision: D45660487
fbshipit-source-id: f1a7a114778a0c2eae963d64558541266ed57bda
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/37316
In Fabric, a ShadowNode may re-initialize YGConfig several times throughout the lifetime of a perpetually cloned Yoga Node.
RN sets `pointScaleFactor` lazily, when laying out the rootview. So right now it initializes a config to `pointScaleFactor` of 1.0, sets it, sets a new `pointScaleFactor` on the config, then repeats. This cycles the config between two `pointScaleFactor` values and will excessively dirty the node now that `YGNodeSetConfig` dirties on config change (D45505089)
This change makes it so that we retain previously used `pointScaleFactor` when cloning the Yoga nodes.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D45669878
fbshipit-source-id: bfd2e185d9264a1cda64e59132960060385e16f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37320
Changelog: [Internal]
this is just my personal taste, but here's what i did, would love to hear others' opinions (and maybe get these eventually codified):
- private methods preprended with underscore
- pragma mark groupings in this order: public, overrides, protocols, then private
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D45582491
fbshipit-source-id: 76c80955422ea7f29e7307ce2c08f70e7e8a5188
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:
It's just a code improvement, with postponement of best practices.
## Changelog:
[Android] [Added] - Code improvement.
Pull Request resolved: https://github.com/facebook/react-native/pull/37297
Test Plan: The new code does not change existing logic.
Reviewed By: NickGerleman
Differential Revision: D45658400
Pulled By: yungsters
fbshipit-source-id: dcbe4b732d665a0c3c26ee2cf28843f951c3979d
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/37207
X-link: https://github.com/facebook/yoga/pull/1274
Yoga exposes public APIs for dirtying Nodes, but will itself perform dirty marking when changing bits which invalidate layout. E.g. changing the style of a Node will invalidate it along with every parent Node.
Because config setting is newly public to the C ABI, this makes a similar change so that replacing a Node's config will dirty the tree above the node if there is a layout impacting config change (I don't think children need to be invalidated since child output shouldn't change given the same owner dimensions).
One quirk of this is that configs may be changed independently of the node. So someone could attach a config to a Node, then change the live config after the fact. The config does not currently have a back pointer to the Node, so we do not invalidate in that case of live config edits. The future work to rectify this would be to make configs immutable once created.
There are also currently some experimental features here which should maybe be compared, but these should be moved to YGErrata anyway.
Reviewed By: javache
Differential Revision: D45505089
fbshipit-source-id: 72b2b84ba758679af081d92e7403750c9cc53cb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37290
This diff removes an assertion that was causing a crash in production.
The root cause of the bug is that there's a race condition on viewState.mEventEmitter, the value of this field changes while the method is being executed.
In this diff I'm avoiding the crash by dispatching the event as soon as possible and unblock the fix in production
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D45622656
fbshipit-source-id: a6ea64e38189676885366931de84dc5433834fff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37246
Changelog: [Internal]
since no one is using this outside of RCTInstance, let's clean this up!
Reviewed By: sammy-SC
Differential Revision: D45553212
fbshipit-source-id: 959fb454ff403c89ec5005b9a602986769cec388
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
Intl Scheduler
Ruslan Lesiutin
Tommy Nguyen
shubham0142
Riccardo Cipolleschi
Blake Friedman
Pieter De Baets
Jerry
Luna Wei
Nick Gerleman
Phillip Pan
axelaviloff
kassens (Meta Employee)
David Vacca
acdlite
gaearon (Meta Employee)
sammy-SC (Meta Employee)andDan Abramov
Lu Su
Ramanpreet Nara
hoxyq (Meta Employee)
sebmarkbage
