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/36030
Generate enum types in c++ turbo modules.
For enums in the ts schema file such as:
```
export enum NumEnum {
ONE = 1,
TWO = 2,
}
```
This would export enums and the relevant Bridging to js and from js code to the spec H files such as:
```
#pragma mark - SampleTurboModuleCxxNumEnum
enum SampleTurboModuleCxxNumEnum { ONE, TWO };
template <>
struct Bridging<SampleTurboModuleCxxNumEnum> {
static SampleTurboModuleCxxNumEnum fromJs(jsi::Runtime &rt, int32_t value) {
if (value == 1) {
return SampleTurboModuleCxxNumEnum::ONE;
} else if (value == 2) {
return SampleTurboModuleCxxNumEnum::TWO;
} else {
throw jsi::JSError(rt, "No appropriate enum member found for value");
}
}
static jsi::Value toJs(jsi::Runtime &rt, SampleTurboModuleCxxNumEnum value) {
if (value == SampleTurboModuleCxxNumEnum::ONE) {
return bridging::toJs(rt, 1);
} else if (value == SampleTurboModuleCxxNumEnum::TWO) {
return bridging::toJs(rt, 2);
} else {
throw jsi::JSError(rt, "No appropriate enum member found for enum value");
}
}
};
```
That code would allow us to use these enums in the cxx files like this:
```
NativeCxxModuleExampleCxxEnumInt getNumEnum(
jsi::Runtime &rt,
NativeCxxModuleExampleCxxEnumInt arg);
```
Changelog: [General] [Added] Generate enum types that would be allowed to be used as well as string/number in c++ turbo modules generators
Reviewed By: christophpurrer
Differential Revision: D42884147
fbshipit-source-id: d34d1fc7ba268b570821dc108444196f69a431b2
Summary:
## Changes
{| ... |} -> { ... }
**Motivation:** In Flow, object literals are exact by default. So, there's no need for the pipes. Also: Now, the syntax for object literals is consistent across react-native-codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24774771
fbshipit-source-id: 24ceb6f5876122aa8ad9e08c7e903215864ad6f5
Summary:
In our Codegen generators, we were using `codegenModuleName` to refer to the name of the spec file. Calling this `hasteModuleName` makes it more clear what this name refers to (i.e: the name of the spec file). This diff performs that rename.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386282
fbshipit-source-id: fe2beda9a0abf63a5cf88fa0664f83416c9f1aa2
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. NativeModule generators now use the new RN Codegen NativeModule schema.
2. Tangential: We're no longer removing the `Native` prefix from the NativeModule filename, assuming that that's the module name (problem: wrong), and prefixing again with Native (problem: redundant), when we're generating code. Instead, like the internal codegen, we simply pass the filename to the Codegen output. Our linters enforce that all NativeModule specs are contained with files that start off with `Native`.
3. `GenerateModuleCpp` was fixed to use the actual module name as opposed to the spec name. I added a comment inline.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236405
fbshipit-source-id: ccd6b5674d252c350be0ec8a86e7ca5f2f614778
Summary:
There are two operations we do in every NativeModule generator:
- We convert the `SchemaType` into a map of NativeModule schemas
- If the type-annotation is a TypeAliasTypeAnnotation, we resolve it by doing a lookup on the NativeModuleAliasMap. This is usually followed by an invariant to assert that the lookup didn't fail.
Both procedures have been translated into utilities for use across our generators. I also deleted `getTypeAliasTypeAnnotation` which will no longer be used.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23667249
fbshipit-source-id: 4e34078980e2caa4daed77c38b1168bfc161c31c
Summary:
This builds on the previous commit and complete all current NativeModule spec support for React Native Android:
* method param (nullable) typing
* promise return support
* sync method
* getConstants() special Android runtime validation
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22862422
fbshipit-source-id: abc6d46fb8ce5863677910de1acc8bb6a927e7da
Christoph Purrer
Moti Zilberman
Vitali Zaidman
Andres Suarez
Ramanpreet Nara
Nat Mote
Kevin Gozali