Summary:
**History:** This component was originally introduced into React Native core in D52712758, to replace UIManagerModule.showPopupMenu().
**Problem:** But, React Native core should be lean. Adding this component to React Native bloats the core.
**Changes:** So, this diff pulls PopupMenuAndroid out into its own package in the react-native GitHub repository.
In the future, this will be migrated to a community package!
Changelog: [Android][Removed] Move PopupMenu out of React Native core
Reviewed By: NickGerleman
Differential Revision: D53328110
fbshipit-source-id: 469d8dc3e756c06040c72e08fa004aafa1bd6e18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43159
Changelog: [internal]
This modifies the default `RCTAppDelegate` for iOS apps in OSS to provide an implementation for the C++ native module for feature flags.
In a following diff I'll replace the `React-featureflagsnativemodule.podspec` file with one that includes all built-in C++ native modules.
Reviewed By: RSNara
Differential Revision: D54082349
fbshipit-source-id: 8c4ed7499c6fd35916ba105edcae0e2c85961e1c
Summary:
This diff renames React-Codegen to ReactCodegen. This way we'll no longer have to try both
```
#include <React-Codegen/MyModule.h>
```
and additionally
```
#include <React_Codegen/MyModule.h>
```
for cases with `use_frameworks`.
Changelog: [iOS][Breaking] - Rename React-Codegen to ReactCodegen
Reviewed By: cipolleschi
Differential Revision: D54068492
fbshipit-source-id: dab8ea2034d299266482929061caa14397421445
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43129
## Changelog:
[Internal] -
C++ side expects "source" property to be an up to date, correctly resolved Image source inside `ImageProps`.
Incidentally, it wasn't the case when:
* we build for an Android platform
* the asset is a "packager asset", i.e. bundled by Metro and included in APK
It hasn't been an issue in the case of "pure" Android platform, as it instead uses "src" prop, instead of source on the Java implementation side, ignoring "source" completely, so the fact that "source" wasn't propagated correctly to C++ in some cases didn't affect Android.
However, there are some new use cases where we'd like to have correct "source" value in C++ as well (and ultimately align this between all the platforms, so it's "source" everywhere, but this is a matter of a separate discussion).
Differential Revision: D54000899
fbshipit-source-id: 9bfb9e7c157cf19ddf396c141b03b75f3b2022e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43118
While debugging issues with precompiled_headers in Instagram, it became apparent that these RN files don't correctly import the necessary files to make them build on their own. Fix that!
Changelog: [iOS][Fixed] Fixed missing header imports
Reviewed By: fkgozali
Differential Revision: D53963676
fbshipit-source-id: 74e9758153f6176133475e45d27f7644d1a6dece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43114
Changelog: [iOS][Breaking]
PR#42628 introduced new behavior on how the react native infra tracks local notifications that start the app. in this PR, we are officially deleting the old implementation.
Reviewed By: ingridwang
Differential Revision: D52931617
fbshipit-source-id: 3b77479b0aacf239e45cfcc7d7c4b20e82e0b786
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43070
**Context**
The `codegenNativeComponent` function is a hint for the codegen that the file that contains it is a Native Component spec. Static ViewConfig codegen overwrites this function call by the generated ViewConfig.
If this function is not overwritten by the codegen, it has runtime behaviour that falls back to `requireNativeComponent`. At the time when this system was built `requireNativeComponent` was not supported in Bridgeless mode because it is relied on some Bridge-only functionality. That's why it outputs error in Bridgeless mode.
---
This is not the case any more, we now have interop layers which provide the functionality needed by `requireNativeComponent`.
The SVC codegen is implemented as [Babel plugin](https://github.com/facebook/react-native/tree/main/packages/babel-plugin-codegen). The are scenarios when it is not run for the native component specs:
- If the plugin is not used for whatever reason.
- If Babel is not used for whatever reason.
In order to not to regress the DevX for such cases, we've turned the error into the warning.
**Note:** we use `console.info('⚠️...` instead of `console.warn('...`. That's because `console.warn` also prints a stack trace in the console, and we didn't want to create too much noise.
Changelog: [General][Changed] - codegenNativeComponent show warning and not error if not code generated at build time.
Reviewed By: huntie, rshest
Differential Revision: D53761805
fbshipit-source-id: c924c7668e6d2e45b920672b8a309221be767a73
Summary:
Changelog: [Internal]
Along with all the places using it like the `_debugSource` on Fiber.
This still lets them be passed into `createElement` (and JSX dev
runtime) since those can still be used in existing already compiled code
and we don't want that to start spreading to DOM attributes.
We used to have a DEV mode that compiles the source location of JSX into
the compiled output. This was nice because we could get the actual call
site of the JSX (instead of just somewhere in the component). It had a
bunch of issues though:
- It only works with JSX.
- The way this source location is compiled is different in all the
pipelines along the way. It relies on this transform being first and the
source location we want to extract but it doesn't get preserved along
source maps and don't have a way to be connected to the source hosted by
the source maps. Ideally it should just use the mechanism other source
maps use.
- Since it's expensive it only works in DEV so if it's used for
component stacks it would vary between dev and prod.
- It only captures the callsite of the JSX and not the stack between the
component and that callsite. In the happy case it's in the component but
not always.
Instead, we have another zero-cost trick to extract the call site of
each component lazily only if it's needed. This ensures that component
stacks are the same in DEV and PROD. At the cost of worse line number
information.
The better way to get the JSX call site would be to get it from `new
Error()` or `console.createTask()` inside the JSX runtime which can
capture the whole stack in a consistent way with other source mappings.
We might explore that in the future.
This removes source location info from React DevTools and React Native
Inspector. The "jump to source code" feature or inspection can be made
lazy instead by invoking the lazy component stack frame generation. That
way it can be made to work in prod too. The filtering based on file path
is a bit trickier.
When redesigned this UI should ideally also account for more than one
stack frame.
With this change the DEV only Babel transforms are effectively
deprecated since they're not necessary for anything.
DiffTrain build for commit https://github.com/facebook/react/commit/37d901e2b81e12d40df7012c6f8681b8272d2555.
Reviewed By: kassens
Differential Revision: D53543159
Pulled By: tyao1
fbshipit-source-id: 8e5509a16ea8d3234881e2305149326fb31e3845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42687
Changelog: [Internal]
adding an example for if you want to use `getInitialNotification`.
Reviewed By: ingridwang
Differential Revision: D52931618
fbshipit-source-id: 7552c358e5bc98228b7ae74ea1adf450f7b075e6
Summary:
Changelog: [Internal]
I'm updating this API to match the semantics of the other new APIs, namely that they're static methods that don't depend on the instance of the native module. This should help streamline our documentation. Instead of capturing the launch notification as an ivar, we capture it in a static variable that we clear out when the object gets cleared or is invalidated, which is similar to an ivar / property.
Reviewed By: ingridwang
Differential Revision: D53743761
fbshipit-source-id: b6ff048ef8d653e8f4be19194a2211792a542252
Summary:
Changelog: [Internal]
In the past, local notifications were stored in the launch options as UILocalNotification, whereas remote notifications were stored as NSDict. This means that we had different handling in PushNotificationIOS.js. This condition was not handling the differences in local and remote notifications that JS expected, which I'm fixing here.
Reviewed By: ingridwang
Differential Revision: D53734086
fbshipit-source-id: 73ef436a232c16de3b72f7236db94012aafdc434
Summary:
Changelog: [Internal]
Required for landing D53543159.
2 reasons for landing this:
1. Inspector is technically deprecated and will be removed once React DevTools are shipped with Chrome DevTools for RN debugging.
2. Long-term solution for source fetching is lazy loading based on component stacks - https://github.com/facebook/react/pull/28265
Reviewed By: kassens
Differential Revision: D53757524
fbshipit-source-id: cbb2aab79ba40ea66da5c1ddde95d3fe374b6006
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42769
Changelog: [internal]
These APIs are not currently enabled in OSS, so moving the modules should be safe and not considered a breaking change.
Reviewed By: NickGerleman
Differential Revision: D53267565
fbshipit-source-id: edd3daa7c5043e44e5fd4b1af074093ed3ef4152
Summary:
The recent change to make onDismiss work on Fabric broke the Modal on Paper (see [this comment](https://www.internalfb.com/diff/D52959996?dst_version_fbid=236415652884499&transaction_fbid=896066412296150)).
This change will fix that behavior.
The problem was that we were resetting the `isRendered` state only when the Modal receives the event from the Event emitter AND if it has the `onDismiss` callback set.
However, we should hide the component in any case if the ids match, and invoke the onDismiss if it is set.
## Changelog
[iOS][Fixed] - Make sure that Modal is dismissed correctly in Paper
Reviewed By: janeli-100005636499545
Differential Revision: D53686165
fbshipit-source-id: a1de0b29dca7c099e9fa0282ec80cae9a8fd6bc3
Summary:
Changelog: [Internal]
`getInitialNotification` only expect the user info dictionary of the dictionary, not the complete formatted notification.
Reviewed By: cipolleschi
Differential Revision: D53691569
fbshipit-source-id: 9a24629d2e50544c55ea5cd16097bd88dad950ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42923
This Diff implement the logic to:
- Read some lists of class names provided by libraries that conforms to some protocols we defined as extension points.
- Generate a provider in the React-Codegen podspec, whose code lives alongside the app code.
- Glue the app and the generated code together, allowing to link custom protocols
## Changelog
[iOS][Added] - Allow libraries to provide module which conforms to protocols meant to be extension points.
Reviewed By: RSNara
Differential Revision: D53441411
fbshipit-source-id: f53bc6ea0417e6122d8918df2614bcb9937a515a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42642
Removes call to `InspectorFlags::initFromConfig`, since this approach is being replaced with `ReactNativeFeatureFlags`. This change is separated out as it originally made a public API deprecation.
Changelog:
[iOS][Deprecated] - **Un-deprecates** `RCTAppSetupPrepareApp` (reverts #41976)
Reviewed By: motiz88
Differential Revision: D53048207
fbshipit-source-id: 8624020f1e9e19f9f1ee75af9b177e922e36c5d9
Summary:
This PR adds nullable annotations to `RCTBundleURLProvider` also allowing to return optional (the default that will be returned when metro is not running). Not having this may lead to crashes because Swift will try to unwrap optional with nil when metro is not running.
## Changelog:
[iOS] [Added] - add nullable annotations to RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/42293
Test Plan: CI Green
Reviewed By: sammy-SC
Differential Revision: D52797676
Pulled By: cipolleschi
fbshipit-source-id: 98b4f99aa71828f5397276d22f35d24e48657dc8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42601
After S390064, the OnDismiss event for Modal from D52445670 was reverted.
The diff was too big and caused the SEV, so we are trying to reimplement it gradually to make sure we don't brake anything.
The most important thing for our short term goal is to make the `OnDismiss` work only for iOS (following the official docs, Android never supported it) for Fabric (Bridge and Bridgeless).
We also want to minimize the changes t the JS infrastructure, so we are trying not to alter the JS APIs.
## The Problem:
The reason why the onDismiss event does not work is because, as soon as the `visible` property is turned to `false`, the component is removed by the React tree.
When this happens, Fabric deallocate the ShadowNode and the EventEmitter. Therefore, the event is not fired.
## The Solution:
We made this work by "delaying" when the component need to be removed from the reacat Tree.
Rather then rendering or node or not based on the `visible` props, we are introducing a `State` object that keeps track when the Modal is rendered or not.
The `state.isRendering` property is set to `true` when the `visible` prop is set to `true`.
For iOS, when `visible` prop is set to `false`, instead, we wait for the Native side to actually dismiss the View and to invoke the event. When the event is fired, we manually set the `state.isRendering` property to false and the Modal can be considered dismissed.
Notice that this makes also useless to have the Modal Native's snapshot to simulate that the modal is still presented.
## Changelog:
[iOS][Fixed] - `onDismiss` now work on iOS with Fabric, in both Bridge and Bridgeless mode.
Reviewed By: sammy-SC
Differential Revision: D52959996
fbshipit-source-id: 365ca1d0234e3742df9db87007523d1a4a86079f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42821
As the title says, we want `concurrentRoot iif fabric`.
This makes sure we invoke renderApplication correctly.
Changelog:
[Internal] [Changed] - Set concurrentRoot to true whenever Fabric is used in renderApplication
Reviewed By: sammy-SC
Differential Revision: D53353017
fbshipit-source-id: 8de88adf528eb71f233233bd85c2c6ef9430fb16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42892
## Changelog:
[Internal]-
This adds an ability to have multiple custom source transformers when resolving asset sources, which is beneficial in some scenarios.
The transformers are chained, being executed in order they are registered, until one of them returns a non-null value.
If none does, then the default one is returned.
Reviewed By: GijsWeterings
Differential Revision: D53472320
fbshipit-source-id: ed9baf8789b8bd41c8ce78eed71ebb65868cf178
Summary:
This PR removes the TypeScript entry for `UIManager.takeSnapshot()`. This function does not appear to be implemented anywhere, and calling it throws `TypeError: _reactNative.UIManager.takeSnapshot is not a function (it is undefined)`.
I think this functionality is still supported by [react-native-view-shot](https://github.com/gre/react-native-view-shot) for anyone who needs it!
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Removed] - Removed type definition `UIManager.takeSnapshot()`
Pull Request resolved: https://github.com/facebook/react-native/pull/42779
Test Plan: Ran TypeScript checks.
Reviewed By: cipolleschi
Differential Revision: D53307137
Pulled By: NickGerleman
fbshipit-source-id: 2e65c58c77bcde4f36f5065295d15757c519239d
Summary:
The previous typing of FlatList and VirtualizedList did not convey any information on the type of the items passed in to `onViewableItemsChanged`, but instead the type was set to `any`. This PR adds the type information.
I set a default type `any` for thy ViewToken, because the type is exported and not having it would be a breaking change if that type is used. Like this it gracefully falls back to the default behavior of the `any` type.
Notice: I don't know how typing in "flow" works, but the same "issue" seems to be in there as well. Maybe someone with more flow experience can fix that as well:
https://github.com/facebook/react-native/blob/ae42e0202de2c3db489caf63839fced7b52efc5d/packages/virtualized-lists/Lists/ViewabilityHelper.js#L19-L20
## Changelog:
[GENERAL] [FIXED] - Add type information for items of VirtualizedList in `onViewableItemsChanged` signature
[GENERAL] [FIXED] - Add type information for items of FlatList in `onViewableItemsChanged` signature
Pull Request resolved: https://github.com/facebook/react-native/pull/42773
Test Plan:
Without the changes, typecheck of the project was fine, but with the changes applied to the node_modules/react-native copy a type error was found:
```
$ npm run typecheck
> my-project@1.0.0 typecheck
> tsc --skipLibCheck
src/MyComponent.tsx:385:29 - error TS2345: Argument of type '(string | number)[]' is not assignable to parameter of type 'number[]'.
Type 'string | number' is not assignable to type 'number'.
Type 'string' is not assignable to type 'number'.
385 viewableItems
~~~~~~~~~~~~~
386 .filter(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Reviewed By: rozele
Differential Revision: D53276749
Pulled By: NickGerleman
fbshipit-source-id: 3fa5c65b388a59942c106286ac502a85c583da50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42635
Changelog: [Internal]
Adds a RuntimeAgent interface to the modern CDP backend, plus an `InstanceTargetDelegate::createRuntimeAgent()` method. This allows the RN integration to provide an engine-specific CDP implementation.
This diff includes all the plumbing in Bridge and Bridgeless to route `createRuntimeAgent()` calls to the right place - ending up at `JSExecutor::createRuntimeAgent()` and `JSIRuntimeHolder::createInspectorAgent` respectively - at which point we currently return `nullptr` to signify that JS debugging isn't supported.
## Next steps
In upcoming diffs we'll add concrete implementations of `RuntimeAgent`, and teach both Bridge and Bridgeless to create them as appropriate:
* `HermesRuntimeAgent` for Hermes
* `FallbackRuntimeAgent` for all other JS engines (JSI or not)
We'll also (likely) add assertions to ensure that any JSI runtime that reports itself as "inspectable" (a flag used to control some of the in-app debugging UI) comes with a non-default `createRuntimeAgent()` implementation. We avoid this for now to prevent crashing the modern backend on Hermes.
NOTE: Like the rest of the modern CDP backend, the `RuntimeAgent` API is 100% experimental and subject to change without notice. A *future* version of this API will allow out-of-tree JSI engines to integrate with the modern CDP backend. Either way, it is intended strictly for the use case of integrating with a JS engine, not for adding any other framework-level CDP functionality.
Reviewed By: huntie
Differential Revision: D51231326
fbshipit-source-id: 81e87c5134df73cc4aac0f9d5793a5236b5720d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42762
This renames `performance.reactNativeStartupTiming` as `performance.rnStartupTiming` to align with the recommended vendor prefix for React Native.
This API is still private, so it's safe to rename.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53264515
fbshipit-source-id: 6e7a222901071594cac0ca8a0ac78e56e60ab132
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42720
The request ID was used for in-memory request caching purpose only. There wasn't much reason to use the sophisticated monotonic number, so let's just use a static 64-bit unsigned int counter. With the more-or-less unique UUID prefix, this should have an extremely low chance of collision.
Changelog: [Internal]
Reviewed By: philIip, sammy-SC
Differential Revision: D53205641
fbshipit-source-id: e6da12029624058dc877e9cbe2000af4df938870
Summary:
The goal is to provide testing utilities that use Fabric and concurrent rendering by default to support the new RN architecture. Currently most testing is done through ReactTestRenderer, which is an overly-simplified rendering environment, non-concurrent by default, and over exposes internals. A dedicated RN environment in JS can allow for more realistic test execution.
This is the initial commit to create the `react-native-test-renderer` package. It currently only offers a simple toJSON() method on the root of a test, which is used for snapshot unit tests. We will be iterating here to add a query interface, event handling, and more.
## Changelog:
[GENERAL] [ADDED] - Added react-native-test-renderer package for Fabric rendered integration tests
Pull Request resolved: https://github.com/facebook/react-native/pull/42644
Test Plan:
```
$> cd packages/react-native-test-renderer
$> yarn jest
```
Output:
```
PASS src/renderer/__tests__/render-test.js
render
toJSON
✓ returns expected JSON output based on renderer component (7 ms)
Test Suites: 1 passed, 1 total
1 passed, 1 total
Snapshots: 1 passed, 1 total
Time: 2.869 s
```
Reviewed By: yungsters
Differential Revision: D53183101
Pulled By: jackpope
fbshipit-source-id: 8e29ba35f55f6c4eb2613ab106bc669d72f33d1d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42636
Changelog: [Internal]
Models the Native instance lifecycle in the modern CDP backend, by:
1. Registering the instance, once created, with `PageTarget`.
2. While an instance is registered, delegating messages from `PageAgent` to an internal `InstanceAgent`.
3. Unregistering the instance once it is invalidated and about to be destroyed.
We use this infrastructure to implement two simple behaviours that will be superseded in future diffs (mainly by delegating work to the JSVM), but that are useful as stubs for testing:
* Sending [`Runtime.executionContextDestroyed`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextDestroyed), [`Runtime.executionContextsCleared`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextsCleared), and [`Runtime.executionContextCreated`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextCreated) events to the frontend when reloading the instance.
* Implementing a toy version of [`Runtime.getHeapUsage`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#method-getHeapUsage) (that always reports zero memory usage) to exercise the Page→Instance message dispatching logic.
iOS Bridge/Bridgeless and `PageTargetTest` are the only integrations that exist as of this diff, and are all updated here; Android will follow later.
## Object lifetimes
* PageTarget owns an InstanceTarget that it creates (in `registerInstance`) and destroys (in `unregisterInstance`).
* `registerInstance` returns a raw `InstanceTarget&` reference, which becomes invalid upon calling `unregisterInstance`. It's the caller's responsibility to stop using the reference at the point of calling `unregisterInstance`.
* InstanceTarget holds a raw `InstanceTargetDelegate&` reference. It's the caller's responsibility to keep this reference valid at least until `unregisterInstance` returns.
## Thread safety
* As with PageTarget's constructor and destructor, It's the caller's responsibility to invoke `registerInstance` and `unregisterInstance` on the main thread (or using appropriate synchronisation).
* `InstanceAgent` handles messages on the same thread as `PageAgent` (typically the platform-specific main thread) and receives a copy of the same thread-safe `FrontendChannel` for sending messages back.
Reviewed By: huntie
Differential Revision: D51214056
fbshipit-source-id: 2dc2ff30d2dda6887871831a818aa117ca3e6e91
Summary:
After update to the latest `react-native` version
we discover that we are unable to use `number%` value for `translate*` props :
```tsx
StyleSheet.create({
root: {
transform: [
{ translateX: '-50%' },
// ^^^^^^ TS Error: Type string is not assignable to type AnimatableNumericValue | undefined
],
}
});
```
---
percentage values are supported, demo: https://snack.expo.dev/retyui/test-tstransform
## Changelog:
[GENERAL] [FIXED] - Update typescript definition of `translateX` & `translateX` to be able to use percentage values
Pull Request resolved: https://github.com/facebook/react-native/pull/42671
Test Plan: `yarn tsc --noEmit`
Reviewed By: rozele, cortinico
Differential Revision: D53146046
Pulled By: NickGerleman
fbshipit-source-id: 3486e7a9b55b98c36cc96b2bca4bb27841061e80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42730
Reviewing and modernising this script as part of simplifying our release publish workflow.
- Drop unused `--dependency-versions` arg from CLI entry point
- Simplify templating approach
- Type as Flow
- Drop dependencies on `shelljs` and `yargs`
- Relocate under `scripts/releases/`
- Rewrite tests as snapshot tests
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53001971
fbshipit-source-id: e55a71a0bb37e3e18ba1e582a5c46ddd58823d81
