Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53135
Our Codegenerated components are not generating code for `getDebugProps`. This change modifies Codegen to add those functions for all the codegen components.
## Changelog:
[General][Added] - Added getDebugProps to codegen
## Facebook:
`getDebugProps` are required by Fantom to write tests. However, we can't generate these function for third party components, because codegen can generate arbitrary structs and we don't have a generic `toString()` method that can be used or automatically generated by C++.
By generating this function only for Core Components, we can ensure that we can write Fantom tests without breaking all the users of React Native.
Reviewed By: rubennorte
Differential Revision: D79805145
fbshipit-source-id: 0e41c65fc30eaa886a05557ca233fb0a9cb18a71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52545
Pull Request resolved: https://github.com/facebook/react-native/pull/51735
This diff refactors the ViewManagerInterfaces codegen to generate kotlin classes,
As a consequence of this change, there are some ViewManagerInterfaces that have changed their APIs
## Changelog: [Android][Breaking] - Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: cortinico
Differential Revision: D78118738
fbshipit-source-id: cdd9e660e55397bd0936efce1c5aaf90c2946b7a
Summary:
reverting Refactor ViewManagerInterfaces codegen to generate kotlin classes because of warning in OSS, we will reland after 0.81 cut
Changelog: [Android][Breaking] - Revert of Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: lenaic, mlord93
Differential Revision: D77759777
fbshipit-source-id: c24b216b231cdc53296d8c9fca8d789d80daa596
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51735
This diff refactors the ViewManagerInterfaces codegen to generate kotlin classes,
As a consequence of this change, there are some ViewManagerInterfaces that have changed their APIs
## Changelog: [Android][Breaking] - Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: javache
Differential Revision: D75719542
fbshipit-source-id: 7e9aa7ccc24e827bd7b6df72b3302e852932e731
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52246
This diff adds the required override to codegen props to make the `FabricMountingManager` aware of the availability of a prop diffing implementation for native components using codegen props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234066
fbshipit-source-id: 8e95628348f491c5ee08609bc7d7b3d30bc7151b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52266
Native components may use `MixedType` properties in rare cases to hold untyped data. This diff adds support for serializing and prop diffing these types of props so that all of the props and object fields would be included in prop diffing results.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77307169
fbshipit-source-id: ae6b00207ef857c9cfa4bdf9c235972915410a29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52244
The ArrayType props converts to std::vector. This prompted the need for `toDynamic(const T&)` conversion functions as this breaks to potential reliance on all type instances having a `toDynamic()` function available. This includes:
- array of arrays types
- array of objects types
- object with arrays
The ArrayType conversion uses the availability of the `toDynamic` conversion methods for all supported types to convert the values stored by the `std::vector` to `folly::dynamic` values to be stored on a `folly::dynamic::array`.
The diff removes unnecessary conversion methods implemented previously for the core components prop diffing. These are now handled by the generic `toDynamic(const std::vector<T>&)` conversion method.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234065
fbshipit-source-id: 97a3b175ff07fe4a6de3adb14ee6cb42db1a2cfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52243
Building on the availability of `toDynamic` conversion methods for all supported property types, this diff adds support for diffing of `ObjectType` props.
The template adds the generation of a default comparator for the generated C++ struct. The struct also gains a `toDynamic` conversion method that will convert each property of the object type to a `folly::dynamic` value.
Primitive types make use of the implicit conversion supported by `folly::dynamic`, all other types are converted using `toDynamic`.
The `toDynamic` logic is implemented as a method defined on the struct to avoid increased binary size when required multiple times by the prop diffing implementation.
The external `toDynamic` conversion function calls the struct method directly. This enables support for converting object types using object types within their props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234064
fbshipit-source-id: 21deb3104303aa374fb65b969af57a6aca6db38c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52242
Codegen supports `DimensionType` props which represents a YGValue. This diff adds a conversion to `folly::dynamic` supporting all the existing value types `YGValue` can represent.
This completes codegen support for all allowed `ReservedPropTypeAnnotation` prop types.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234061
fbshipit-source-id: 6c3aef5e3ab0459d8a68ebd8efaccfecb83b0b08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52241
Add support for converting string and int32 enum types to `folly::dynamic` and generating the correct property diffing for it conditionally adding the prop value to the prop diff result.
This diff updates the template to convert the enum back to the original string representation provided from the JS side based on the current generated C++ enum value.
The string enum re-uses the existing `toString` conversion. The number enum generates the switch-case mapping required to map back the C++ enum value to the original value assigned to it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234070
fbshipit-source-id: 8c669d5b2e21bd6022c6ba36149465495e4d4bf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52238
Add prop diffing codegen for `PointPrimitive` prop type by adding a `toDynamic` conversion for the struct and the prop diffing conditional result update.
The addition of the `toDynamic` function will allow for converting the type when used in array and object types.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234062
fbshipit-source-id: d0f52e8fd78ac7712925ea2a47cdd0fe3392d5b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52237
For array props conversion following later in this stack, each type should have a toDynamic conversion available that can be called upon to convert all supported types to a `folly::dynamic` result.
This diff adds the toDynamic conversion function for `ImageSource`
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234063
fbshipit-source-id: 392cbaf172595936f7f66faa824900dadd58bdcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51650
This diff adds support to diff props with Point type
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75469451
fbshipit-source-id: a6844b691d8e32326d04c2bd51e6509980feb611
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/49950
Changelog: [GENERAL][CHANGED] - Changed `react-native-codegen` to support types under `CodegenTypes` namespace
## Summary
Currently, codegen relies on deep importing types under `react-native/Libraries/Types/CodegenTypes` to be properly type-checked. Updating codegen to support types under a single namespace will enable us to provide a single import from the package with access to all relevant types.
Reviewed By: huntie
Differential Revision: D70967809
fbshipit-source-id: 41241dcc51965f4243acd34e8b63475cb56ca67a
Summary:
`jscodeshift` is only used in one module (`src/generators/components/GenerateViewConfigJs.js`, but depends on a rather complex dependency chain and has a rather large maintenance burden relative to what it's used for and the value it adds in the codebase.
Since the `GenerateViewConfigJs` module creates simple templates, using `babel/core` (and implicitly `babel/template` and `babel/types`) is a lot simpler and changes little code. The only change this introduces to the output are formatting changes (`singleQuote` and `trailingCommas` options are discarded). The code is otherwise functionally identical.
## Changelog:
[INTERNAL] [CHANGED] - Drop jscodeshift dependency from react-native/codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/49641
Test Plan:
This was tested against a React Native build with the `react-native/babel-plugin-codegen` plugina active and using the snapshots in the repo itself. While the snapshots have changed in formatting, none of the outputs change the code's AST.
<details>
<summary>
Example output from <code>react-native/babel-plugin-codegen</code> to supplement the snapshot tests
</summary>
This is the example bundling output of `AndroidSwipeRefreshLayout`. This demonstrates that both the view config output and the `Commands` export continue to be generated correctly.
```js
var _interopRequireDefault = require(_dependencyMap[0]);
Object.defineProperty(exports, "__esModule", {
value: true
});
exports.default = exports.__INTERNAL_VIEW_CONFIG = exports.Commands = undefined;
var _codegenNativeCommands = _interopRequireDefault(require(_dependencyMap[1]));
var _codegenNativeComponent = _interopRequireDefault(require(_dependencyMap[2]));
var React = _interopRequireWildcard(require(_dependencyMap[3]));
function _getRequireWildcardCache(e) { if ("function" != typeof WeakMap) return null; var r = new WeakMap(), t = new WeakMap(); return (_getRequireWildcardCache = function (e) { return e ? t : r; })(e); }
function _interopRequireWildcard(e, r) { if (!r && e && e.__esModule) return e; if (null === e || "object" != typeof e && "function" != typeof e) return { default: e }; var t = _getRequireWildcardCache(r); if (t && t.has(e)) return t.get(e); var n = { __proto__: null }, a = Object.defineProperty && Object.getOwnPropertyDescriptor; for (var u in e) if ("default" !== u && {}.hasOwnProperty.call(e, u)) { var i = a ? Object.getOwnPropertyDescriptor(e, u) : null; i && (i.get || i.set) ? Object.defineProperty(n, u, i) : n[u] = e[u]; } return n.default = e, t && t.set(e, n), n; }
var NativeComponentRegistry = require(_dependencyMap[4]);
var _require = require(_dependencyMap[5]),
ConditionallyIgnoredEventHandlers = _require.ConditionallyIgnoredEventHandlers;
var _require2 = require(_dependencyMap[6]),
dispatchCommand = _require2.dispatchCommand;
var nativeComponentName = 'AndroidSwipeRefreshLayout';
var __INTERNAL_VIEW_CONFIG = exports.__INTERNAL_VIEW_CONFIG = {
uiViewClassName: "AndroidSwipeRefreshLayout",
directEventTypes: {
topRefresh: {
registrationName: "onRefresh"
}
},
validAttributes: {
enabled: true,
colors: {
process: (req => 'default' in req ? req.default : req)(require(_dependencyMap[7]))
},
progressBackgroundColor: {
process: require(_dependencyMap[8]).default
},
size: true,
progressViewOffset: true,
refreshing: true,
...ConditionallyIgnoredEventHandlers({
onRefresh: true
})
}
};
var _default = exports.default = NativeComponentRegistry.get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
var Commands = exports.Commands = {
setNativeRefreshing(ref, value) {
dispatchCommand(ref, "setNativeRefreshing", [value]);
}
};
```
</details>
Reviewed By: yungsters
Differential Revision: D70580474
Pulled By: elicwhite
fbshipit-source-id: 85bc6578b685f19a1565ded8d7e56dc2a1ff1999
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49792
This removes the `$` from the `event` and `payload` identifier inside codegen.
This is causing the `-Wdollar-in-identifier-extension` warning to fire.
As I'm looking into enabling `-Wall -Werror` for React Common, this should be addressed as well.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D70500543
fbshipit-source-id: c593680961b1b98561c3985f92ade5d6ba448ac9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49601
Changelog: [internal]
This creates a new module in React Native to define some of the types related to `HostInstance` that are currently defined in `ReactNativeTypes` (synced from the React repo).
We want to remove the types from `ReactNativeTypes` so this is a necessary initial step.
Reviewed By: huntie
Differential Revision: D69996010
fbshipit-source-id: 21cfed4c222e22332936e56aca895fe578809792
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49332
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates `Libraries/Utilities/differ/*.js` to use the export syntax.
- Updates deep-imports of these files to use `.default`
- Updates codegen with a compat layer
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to `Libraries/Utilities/differ/...` with `require` syntax need to be appended with '.default'.
Reviewed By: yungsters
Differential Revision: D69467423
fbshipit-source-id: 2e58a0b9711e9bdf5ca907a5b2252584f6fec9bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49324
Provide Android component codegen a bit more flexibility by allowing `$ReadOnlyArray<UnsafeMixed>` and avoid casting in the view manager.
Changelog: [General][Added]
Reviewed By: fabriziocucci
Differential Revision: D69454101
fbshipit-source-id: c210647deffeb01b7db8aa07266e58c42acf14ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49063
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Updates react-native-codegen to generate ViewConfigs that are compatible with react-native both before and after the export syntax migration.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D68894819
fbshipit-source-id: fca46c1b91c15e22f1e1128ce8621c05341e2fe6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48905
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates `Libraries/StyleSheet/processColorArray.js` to use `export` syntax.
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updated View Config codegen (requires an MSDK bump).
- Updates the public API snapshot *(intented breaking change)*
Changelog:
[General][Breaking] - Files inside `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68564304
fbshipit-source-id: 2fbd058be1a715cccfce4f2a68146118d8ac66ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48609
# Motivation
This is an attempt at modernizing the export syntax in some of the files in `Libraries/StyleSheet/`. It will allow these files to get properly ingested by modern Flow tooling.
# This diff
- Migrates the use of `module.exports` into `export default` for files located in `Libraries/StyleSheet/*.js`. Some files were omitted due to ballooning complexity, but will be addressed in other Diffs.
- Updating internal *require*s to use ".default", no product code seems to be affected.
- Migrating `require`s into `import`s where applicable, taking into account the performance implications (context: https://fb.workplace.com/groups/react.technologies.discussions/permalink/3638114866420225/)
- Updates the current iteration of API snapshots (intended).
- Updates `react-native-codegen`'s require of processColorArray, analogous to D42346452.
Changelog:
[General][Breaking] - Deep imports from some files in `StyleSheet/` can break when using the `require()` syntax, but can be easily fixed by appending `.default`
Reviewed By: javache
Differential Revision: D68017325
fbshipit-source-id: 3c5b94742f101db0b2914c91efab6003dba2b61a
Summary:
This PR fixes the code for generating EventEmitter C++ code in case nested objects in arrays are used.
```typescript
export interface NativeProps extends ViewProps {
onEvent: DirectEventHandler<
Readonly<{
payloadArray: Readonly<
{
obj: Readonly<{ str: string }>
}[]
>
}>
>;
}
export default codegenNativeComponent<NativeProps>('SomeComponent');
```
In this case the generated `EventEmitters.cpp` code would contain:
```c
obj.setProperty(runtime, "str", payloadArrayValue,obj.str);
```
while
```c
obj.setProperty(runtime, "str", payloadArrayValue.obj.str);
```
is expected.
## 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] [FIXED] - Codegen: Support nested objects in arrays
Pull Request resolved: https://github.com/facebook/react-native/pull/47514
Test Plan: Tested with the reproduction case above to verify correct output.
Reviewed By: javache
Differential Revision: D65848670
Pulled By: elicwhite
fbshipit-source-id: 0021e87bc7213fff615465cab8554cc1a2159522
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46809
BaseViewManagerInterface isn't adding much value right now. It was added in D16984121 to allow codegen generated ViewManager delegates to apply to view managers which derive from ViewMangager instead of BaseViewManager (if they did some cleverness, to make VM delegate apply to a no-op class, still implementing all of BaseViewManager's methods).
All of the cases where that was used have since been moved to `SimpleViewManager`, and `BaseViewManagerAdapter` (needed to wire this together) doesn't exist anymore, so it's not possible to take any advantage of this interface existing. We should remove it, since its existence is a source of error (e.g. it was missing setters for `accessibilityValue` or those related to pointer events), and is more generally confusing for anyone adding to `BaseViewManager` in the future.
This is a breaking change, because there are some libraries which vendor a copy of generated ViewManagerDelegate when building against legacy arch to be able to share code normally generated at build time. That means these will need to be updated to maintain compatibility with RN versions of 0.77+ with new arch disabled. This will not effect compatibility of these libraries against the default new arch, and the updated delegate is still compatible with older RN version.
```
sourceSets.main {
java {
if (!isNewArchitectureEnabled()) {
srcDirs += [
"src/paper/java",
]
}
}
}
```
1. `react-native-picker/picker`
2. `rnmapbox/maps`
3. `react-native-gesture-handler`
4. `react-native-screens`
5. `react-native-svg`
6. `react-native-safe-area-context`
7. `react-native-pdf`
Changelog:
[Android][Breaking] - Remove BaseViewManagerInterface
Reviewed By: cortinico
Differential Revision: D63819044
fbshipit-source-id: 7e4935c8e43706b168f0f599a6676e8abfa66937
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/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/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:
The motiviation of this change is to produce sorted / stable native module schemas which members are alphabetically sorted. The benefit is mainly for verifying test fixtures as now new test cases will be inserted at predicatable spots.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56741776
fbshipit-source-id: 842af73cac3b4859d2074e6a5206015924e87201
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
Christoph Purrer
David Vacca
Riccardo Cipolleschi
Nicola Corti
Nick Lefever
Tim Yung
Yannick Loriot
Jakub Grzywacz
Jakub Piasecki
Phil Pluckthun
Rubén Norte
Iwo Plaza
Pieter De Baets
Dawid Małecki
Rayner Kristanto
Tom Van Laerhoven
Nick Gerleman
zhongwuzw