Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50317
`rncore`, `FBReactNativeSpec` and `FBReactNativeComponentSpec` contain the same symbols, which leads to conflicts when we try to merge them into a single shared library. Cleanup the duplication and standardize on `FBReactNativeSpec` everywhere. I've left the Android OSS targets names as is, to avoid breaking deps.
This aligns react-native's package.json with the codegen tooling supported across iOS and Android, which is a single target for all all type-derived codegen.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55037569
fbshipit-source-id: dbf3c0a427c9d0df96e439b04e5b123cd1069c51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51619
RNTester Android is currently instacrashing in OSS due to 3rd-party packages not having the `RN_SERIALIZABLE_STATE` definition.
That's because the `INTERFACE` definition is not properly propagated on the prefab boundaries.
This was happening for `react-native-popup-menu-android` and `react-native-test-library` and will also happen for Codegen libraries.
This fixes it. 3p developers with custom CMake files will also have to use the `target_compile_reactnative_options` functions to make sure the compilation flag are properly populated.
Changelog:
[Android] [Breaking] - Correctly propagate RN_SERIALIZABLE_STATE to 3rd party CMake targets. Users with custom CMake and C++ code should update to use `target_compile_reactnative_options` inside their CMakeLists.txt files. See the 0.81 release notes for more information.
Reviewed By: cipolleschi
Differential Revision: D75441245
fbshipit-source-id: 3855fdf11cbe7f4b01f68e0dde68b63b3240ad35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51502
While working on a case for Editor on mac, it took me a while to figure out what enum was the root cause:
{F1978470518}
Adding the blaming enum name in the error message would have made my life much easier.
## Changelog:
[GENERAL][Added] - Improve error messages when enum members are missing
Reviewed By: rshest
Differential Revision: D75141414
fbshipit-source-id: 3625d817b218788891252add225f8fffb99e3145
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50592
For unclear reasons this is crashing on some devices when dereferencing the module ref. Instead we can just access the existing global_ref to the module instance and avoid any deallocation timing issues.
Also added some additional safeguards and validation against incorrect JNI invocations.
Changelog: [Android][Fixed] Fix crash when TurboModule event emitters are used on arm32
Reviewed By: cortinico
Differential Revision: D72716972
fbshipit-source-id: 3803329048d8388b3d30c9cb55a857e399569eea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49284
All of the CMake library names in the "renderer" directory use "render" for the name, missing the last two letters of the directory name.
eye_twitch
I don't think fixing that should be breaking, since 3p libraries need to rely on the merged library anyway, so let's fix that and find/replace all these.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D69338892
fbshipit-source-id: d3b306ad0ea191728dfbacf9e2aaa12b00caa619
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47349
This is needed to be able to recurse into the literals and compare them.
I'm primarily unsure if there is a problem representing doubles/floats as numbers instead of strings though.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65284058
fbshipit-source-id: b2de9ed5fb7f079a432c94aaea69027863879909
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47324
I need to reference this type somewhere else, but not an array of the type.
Generally we prefer that all exported types are the object itself, and it used as a member type of arrays when used.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65259014
fbshipit-source-id: 35fb5fe03a44bed61ad87337d0fc5c198744c0e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47323
This change adds support for number literals as a type.
The codegen already has parsing support for these types
```
+passNumber: (arg: number) => void;
+passString: (arg: string) => void;
+passStringLiteral: (arg: 'A String Literal') => void;
```
This change now also supports
```
+passNumberLiteral: (arg: 4) => void;
```
On the native side this is treated the same as `number`. It could be strengthened in the future.
This is a pre-requisite for number literal unions and enums.
Changelog: [Added] Codegen: Added support for Number literals in native module specs
Reviewed By: makovkastar
Differential Revision: D65249334
fbshipit-source-id: 98b051d2a6bd1ad5cc6473ac88acfcbe82bd5c7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47229
Adding a test case for an enum value in a fromNative position
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65038107
fbshipit-source-id: ed323d9a8b226be3ff571c86fda617cabc17cdb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47109
Fixes the `lint/sort-imports` errors that are now surfaced after fixing the lint configuration.
For a couple files, I added lint suppressions instead because the unsorted import ordering is important due to interleaved calls with side effects.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D64569485
fbshipit-source-id: 26415d792e2b9efe08c05d1436f723faae549882
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46845
Previously, the parser was throwing away the values of a string union when storing it in the schema. It would only store the union as
```
{
type: 'UnionTypeAnnotation',
memberType: 'StringTypeAnnotation'
}
```
We now track the string literals through the parser and store them in the schema:
```
{
type: 'StringLiteralUnionTypeAnnotation',
types: [
{
type: 'StringLiteralTypeAnnotation'
value: 'light'
},
{
type: 'StringLiteralTypeAnnotation'
value: 'dark'
},
],
}
```
We aren't changing the generators, those still just output "string". They could eventually be made smarter.
The value of this is that the compat checker can now error when the union changes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D63917685
fbshipit-source-id: 34a10e1f1910d2935837a3659f66049fd4473134
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46827
You can now define a native module that takes an argument that is a specific string literal:
Like this:
```
export interface Spec extends TurboModule {
+passString: (arg: string) => void;
+passStringLiteral: (arg: 'A String Literal') => void;
}
```
On the native side, this will still generate `string`, but the schema will now store the string literal, and it will be allowed in JS. This should allow more strict flow / typescript types for modules.
This will also allow the compatibility check to fail if the literal changes.
This is a step towards accepting a union of string literals.
Changelog: [General][Added] Codegen for Native Modules now supports string literals
Reviewed By: GijsWeterings
Differential Revision: D63872440
fbshipit-source-id: e54b97d34af4a3d1af51727db0777f26fb7b778c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46747
You can now use unions in native modules.
Support for this pretty much existed, but one callsite was throwing for non-cpp modules which meant nobody could use this.
Previously, StructCollector would throw that this was not supported because it couldn't generate it for objc. Instead of generating something smart in the native code for each option, it just tells native to treat them like the base type (number, string, object).
Changelog: [General][Added] Codegen now supports Union Types in NativeModules
Reviewed By: GijsWeterings
Differential Revision: D63664505
fbshipit-source-id: 73278ed9cd64452173c5170aba44ced71181510f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46788
Changelog: [internal]
This fixes the reported keys for C++ TurboModules:
```
import MyNativeCppModule from 'MyNativeCppModule';
Object.keys(MyNativeCppModule); // [] - expected
Object.keys(Object.getPrototypeOf(MyNativeCppModule)); // [] - NOT expected
```
Before, we were trying to read the properties from the method map in the public `TurboModule`, but in this implementation all the logic is actually in its delegate (also a `TurboModule` instance, yeah, confusing).
This fixes the issue by forwarding the call to the delegate that has the right information.
Reviewed By: javache
Differential Revision: D63761381
fbshipit-source-id: 90bd216efa0f60352c5ca341d210d83239c80dba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46751
rubennorte noticed that some turbo module methods were not getting cached on the jsRepresentation as expected. This is caused by the react-native-codegen wrappers we generate overriding the `get` method and bypassing this caching layer. Instead they should be overriding `create` to lazily allocate new properties. To prevent this from re-occuring, I've made `get` final so no other overrides can happen.
## Changelog:
[General][Fixed] Properties for C++ TurboModules using codegen were not correctly cached
[General][Breaking] TurboModule::get is now a final method, override `create` to customize property lookup
Reviewed By: rubennorte
Differential Revision: D63665966
fbshipit-source-id: c614901c2f0d698147ec9ba36a4b592ed3d37652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46727
It makes scripts operating on the schema complicated when the elementType might be there or might not. Let's make it required, but VoidTypeAnnotation if it's unknown.
Arguably we shouldn't allow it to be unknown at all, but that's out of scope here.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D63616703
fbshipit-source-id: 290586384b911928e55344aa522bd296f23a074c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46222
This value was typed as always being a string, even though it was containing both strings and numbers in the fixtures. This was because on this line https://fburl.com/code/9j7gh4av the input type is $FlowFixMe (from the source AST), which wasn't catching that it couldn't flow into just `string`.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61830075
fbshipit-source-id: 0d5a0239d7c0209049184ca858a7ceb1ada02f79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46221
Previously the schema special cased unparseable elementType with elementType just being undefined. This causes issues for logic that requires recursively matching types. Instead of being implicit, this makes them explicitly an AnyTypeAnnotation
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61825742
fbshipit-source-id: 47bf70d32d21647896d8f5319087378cc8ac8d4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46220
We'll want to eventually combine the module and component capabilities more, but these are at least the trivially shared ones.
More work is required to merge the more complex object types.
This change also makes it more clear where capabilities are different between native modules and components
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61740140
fbshipit-source-id: 9e7bf740cf6cd2431be8cad822ec69903dbbc71f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43909
As we're moving towards a single `libreactnative.so` file, we need to remove several of our prefab targets. Here I'm cleaning up those that are not having an OnLoad.cpp file which needs to be loaded from SoLoader.
This is breaking for libraries using native dependencies via Prefab (i.e. search for `ReactAndroid::` in CMakeLists.txt files for your project).
If so, the CMakeLists.txt files should be updated as follows:
```diff
- ReactAndroid::react_render_debug
+ ReactAndroid::reactnative
```
This applies to every prefab dependencies (the example is just for `react_render_debug`
Changelog:
[General] [Breaking] - Remove several libs from default App CMake setup
Reviewed By: cipolleschi
Differential Revision: D55751683
fbshipit-source-id: 3aca7897852b5f323d60ede3c5036cae2f81e6c3
Summary:
This migrates the `test_js` workflow to GHA
## Changelog:
[INTERNAL] - Migrate test_js to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/45246
Test Plan: Will wait for CI
Reviewed By: javache
Differential Revision: D59270333
Pulled By: cortinico
fbshipit-source-id: e77eb9819e0819638c51e61b1e477ac04680a2f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45207
These are their own shared library, and their own soloader-call, but they can easily be pulled into existing targets without causing excessive bloat.
Changelog: [Android][Removed] react_newarchdefaults is no longer a prefab, instead use fabricjni
Reviewed By: christophpurrer
Differential Revision: D59107105
fbshipit-source-id: fb3b25f3ce4511aa18126477f2beefe1292c6d09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44919
## Changelog:
[Internal] [Fixed] - Call Turbo Module methods 'methods' in the Turbo Module JSON schema
We don't support `properties` on Turbo Modules. We only support methods (even eventEmitters are just methods)
Reviewed By: javache
Differential Revision: D58510557
fbshipit-source-id: 02b1dc93a37b58b47bb9fd94a9658b5a7301bf55
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44809
Adding react-native-codegen parser support for a new `EventEmitter` property type on C++ Turbo Modules.
It is possible to later expand this feature to other languages (Java, ObjC).
## Characteristics
An `EventEmitter` must:
- be non null:
`EventEmitter<string>` works, `?EventEmitter<string>` does NOT
- have a non null eventType:
`EventEmitter<number>` works, `EventEmitter<?number>` does NOT
- have at most 1 eventType, `void` is possible as well:
`EventEmitter<>` or `EventEmitter<MyObject>` work - `EventEmitter<number, string>` do NOT
- have a concrete eventType, `{}` is not allowed
`EventEmitter<{}>` does NOT work
- be used in `Cxx` Turbo Modules only at this time
## Example
For these 4 eventEmitters in on an RN JS TM spec
```
+onPress: EventEmitter<void>;
+onClick: EventEmitter<string>;
+onChange: EventEmitter<ObjectStruct>;
+onSubmit: EventEmitter<ObjectStruct[]>;
```
We now generate this code:
1.) in the spec based header `{MyModuleName}CxxSpec` in the constructor:
```
... // existing code
eventEmitterMap_["onPress"] = std::make_shared<AsyncEventEmitter<>>();
eventEmitterMap_["onClick"] = std::make_shared<AsyncEventEmitter<OnClickType>>();
eventEmitterMap_["onChange"] = std::make_shared<AsyncEventEmitter<OnChangeType>>();
eventEmitterMap_["onSubmit"] = std::make_shared<AsyncEventEmitter<OnSubmitType>>();
```
2.) as `protected` functions
```
void emitOnPress() {
std::static_pointer_cast<AsyncEventEmitter<>>(delegate_.eventEmitterMap_["onPress"])->emit();
}
void emitOnClick(const OnClickType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnClickType>>(delegate_.eventEmitterMap_["onClick"])->emit(value);
}
void emitOnChange(const OnChangeType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnChangeType>>(delegate_.eventEmitterMap_["onChange"])->emit(value);
}
void emitOnSubmit(const OnSubmitType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnSubmitType>>(delegate_.eventEmitterMap_["onSubmit"])->emit(value);
}
```
## Changelog:
[General] [Added] - Add EventEmitter code-gen support for C++ Turbo Modules
Reviewed By: javache
Differential Revision: D57407871
fbshipit-source-id: 2345cc6dacf0cb0d45f8a374ad9d4cbf8082f9d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44631
Changelog:
[General][Breaking] Use hasteModuleName for C++ Turbo Module enums
This is a follow up to https://github.com/facebook/react-native/pull/44630
This changes the names of C++ Turbo Modules enums to use the `hasteModuleName`.
Example: `NativeMyAbcModule.js` with this spec:
```
export enum EnumNone {
NA,
NB,
}
export interface Spec extends TurboModule {
+getStrEnum: (arg: EnumNone) => EnumStr;t
}
export default (TurboModuleRegistry.get<Spec>('MyAbcModuleCxx'): ?Spec);
```
Before now we generated a base C++ struct with the name:
```
MyAbcModuleCxxEnumNone
^^^
```
Now the generate name is:
```
NativeMyAbcModuleEnumNone
^^^^^^
```
## Changes:
- No `Cxx` injected anymore
- Ensure base struct is `Native` prefixed (all RN JS TM specs start with it)
Reviewed By: cipolleschi
Differential Revision: D57602082
fbshipit-source-id: 9ebd68b8059dfbc6e2ec11065915cf049aa3cb0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44630
Changelog:
[General][Breaking] Use hasteModuleName for C++ Turbo Module structs
This changes the names of C++ Turbo Modules structs to use the `hasteModuleName`.
Example: `NativeMyAbcModule.js` with this spec:
```
export type ValueStruct = {
x: number,
y: string,
z: ObjectStruct,
};
export interface Spec extends TurboModule {
+getValueStruct: () => ValueStruct
}
export default (TurboModuleRegistry.get<Spec>('MyAbcModuleCxx'): ?Spec);
```
Before now we generated a base C++ struct with the name:
```
MyAbcModuleCxxValueStruct
^^^
```
Now the generate name is:
```
NativeMyAbcModuleValueStruct
^^^^^^
```
## Changes:
- No `Cxx` injected anymore
- Ensure base struct is `Native` prefixed (all RN JS TM specs start with it)
## Why?
- The `Cxx` extension is a temporary hint to react-native-codegen to enable extra capabilities and might disappear eventually
- The C++ base struct name should be 'stable'
- The name of the exported TM JS spec `TurboModuleRegistry.get<Spec>(...)` is abritrary, the hasteName is not
- The name of the RN JS TM spec must start with `Native` which better guarantees a consistent naming scheme for these generated base class
- The C++ Turbo Module base class has now the same prefix as the generated structs - `NativeMyAbcModule` for the example above
Reviewed By: cipolleschi
Differential Revision: D57599257
fbshipit-source-id: 4fafe6c7e920737fa766bd7e8e68e521f608e775
Summary:
Changelog: [General][BREAKING] Don't support 'float' enums in Turbo Modules
- The current implementation of 'float enums' in C++ does not work as invalid results are returned.
- At potential fix could still cause rounding errors when crossing language bounaries, e.g. `4.6` can become `4.5599999942..`
- C++ enum classes don't support float: https://eel.is/c++draft/dcl.enum#2.sentence-4
> The type-specifier-seq of an enum-base shall name an integral type; any cv-qualification is ignored.
Hence removing the feature of `float enums` for now
Reviewed By: NickGerleman
Differential Revision: D52120405
fbshipit-source-id: 3685ad0629e16ff9db424ba67e07d09df6027553
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44005
When using frameworks on iOS, there is a possibility that modules import the Spec.h file twice and this might end up in a Redefinition of some symbols and duplication of symbols which ends up in build errors, as reported here: https://github.com/facebook/react-native/issues/42670.
This change adds some [`#include guards`](https://en.wikipedia.org/wiki/Include_guard) in codegen to avoid the redefinition of those symbols if the header is imported/included multiple times.
Note: I also experimented with `#pragma once`, but it looks like Apple is not happy with that directive. [It seems](https://forums.developer.apple.com/forums/thread/739964) that it started working flakely from Xcode 15.
## Changelog:
[General][Fixed] - Make sure that we can't include Codegen symbols multiple times
Reviewed By: cortinico
Differential Revision: D55925605
fbshipit-source-id: 15ca076aace2ffbd03ab8fa8a68a3d8ce0d1ea65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43385
`rncore` and `FBReactNativeComponentSpec` contain the same symbols, which leads to conflicts when we try to merge them into a single shared library. Cleanup the duplication and standardize on `FBReactNativeComponentSpec` everywhere. I've left the Android OSS targets as is, to avoid breaking deps.
Changelog: [Internal]
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54630694
fbshipit-source-id: 75cb961ded9fd75508755c0530e29409fef801cf
Summary:
Changelog: [General][Breaking] Native modules using the codegen now throw an error when called with `null` for optional but not nullable arguments.
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value?: number): void;
```
And you call it like this:
```
NativeModule.someMethod(null);
```
The app doesn't throw an error, but it should because this method shouldn't accept `null` according to its type definition.
## Changes
This modifies the codegen to only check for `undefined` in those cases, otherwise trying to cast the value to the expected type and failing if it's `null`.
NOTE: this is technically a breaking change, but if people are using Flow or TypeScript in their projects they're very unlikely to hit this case, because they would've complained if you tried to pass `null` in these cases.
Reviewed By: cipolleschi
Differential Revision: D54206289
fbshipit-source-id: 58f2f2f3009d203b96189d3c66d1ae98a9e4fb36
Summary:
After discussing with mdvacca, we prefer to undo the change of `TurboModule` package to `.internal` as this is a quite aggressive breaking change for the ecosystem.
Moreover: users should not invoke `TurboModule.class.isAssignableFrom` because `TurboModule` is `.internal`. Therefore I'm exposing another API to check if a class is a TurboModule as a static field of `ReactModuleInfo`.
## Changelog:
[INTERNAL] - Do not use TurboModule.class.isAssignableFrom
Pull Request resolved: https://github.com/facebook/react-native/pull/43219
Test Plan: Tests are attached
Reviewed By: mdvacca, cipolleschi
Differential Revision: D54280882
Pulled By: cortinico
fbshipit-source-id: 9443c8aa23cf70dd5cfe574fe573d83313134358
Summary:
Changelog: [General][Fixed] Fixed crash when passing fewer arguments than expected in native modules using codegen
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value: number): void;
```
And you call it like this:
```
NativeModule.someMethod();
```
The app crashes.
This happens because the codegen tries to cast the value to the expected type without checking if the argument is within the bounds of the arguments array.
## Changes
This fixes that issue with a change in the codegen to guard against this in the generated code (see changes in the snapshot tests).
Reviewed By: RSNara
Differential Revision: D54206287
fbshipit-source-id: 575af462725515928f8634fccc7a9cb51ca0ce4f
Summary:
Changelog: [General][Fixed] Fixed crash when passing non-numeric values where RootTag is expected to methods in native modules using codegen
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value: RootTag): void;
```
And you call it like this:
```
NativeModule.someMethod('');
```
The app crashes.
This happens because we cast the JS value to a C++ value using the method that asserts (`toNumber`) instead of the one that throws a JS error (`asNumber`).
## Changes
This fixes the crash by using `asNumber` instead of `toNumber`.
Reviewed By: RSNara
Differential Revision: D54206288
fbshipit-source-id: 9398112667e0f26edaf4f8f3b32e79fa8aafde62
Summary:
Autolinking local app fabric component requires user to manipulate the C++ code.
This removes this requirement by generating the code necessary to register all the discovered Fabric Components.
I've updated the RN-Tester Android setup to use this mechanism also.
Changelog:
[Android] [Fixed] - Fix autolinking for local app Fabric components
Reviewed By: cipolleschi
Differential Revision: D53710676
fbshipit-source-id: 667af4bcf7fa99563081330aa64d072faf50863b
Pieter De Baets
Nicola Corti
Yannick Loriot
Tim Yung
Nick Gerleman
Eli White
Sam Zhou
Rubén Norte
Christoph Purrer
Pieter De Baets
zhongwuzw
Riccardo Cipolleschi
Dmitry Rykun