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:
Pull Request resolved: https://github.com/facebook/react-native/pull/48476
Command param array types were generating invalid schemas due to untyped parser code. The invalid schemas occurred for any alias type, including custom objects and basics like Int32. This was also inconsistent between Flow and TypeScript.
We already had one component utilizing this issue, so this just codifies that support into the schema so it reflects reality. This is only a partial solution. The more full solution would be to fully encode the custom types in the schemas like we do for Native Modules.
# More Information:
Tl;dr, DebuggingOverlay is abusing a FlowFixMe in codegen commands.
## The problem:
The [CodegenSchema](https://www.internalfb.com/code/fbsource/[d3ab2f79b377]/xplat/js/react-native-github/packages/react-native-codegen/src/CodegenSchema.js?lines=220) should be the source of truth for anything that can be in the schema. If something is in the schema that isn't allowed by the types, that's a bug. We have a bug. I'm adding compat-check support for components and it's blowing up on prod schemas because DebuggingOverlay causes an invalid schema.
## The details:
Support for Arrays as arguments in commands was added to the Codegen in D51866557. [Code Pointer](https://fburl.com/code/8yy1rm0p)
The intention appears to be to support arrays of primitives. There is a TODO for supporting complex types.
```
interface NativeCommands {
+addOverlays: (
viewRef: React.ElementRef<NativeType>,
overlayColorsReadOnly: $ReadOnlyArray<string>,
)
}
```
This support was added to TypeScript in D52046165 where it types the allowed Array arguments to be only
```
{
readonly type: 'ArrayTypeAnnotation';
readonly elementType:
| Int32TypeAnnotation
| DoubleTypeAnnotation
| FloatTypeAnnotation
| BooleanTypeAnnotation
| StringTypeAnnotation
};
```
However, because the Parsers are treating the input type as `any`, it isn't safe to pass through an input value into the schema as Flow won't catch mismatches.
The Flow parser just passes it through:
```
{
type: 'ArrayTypeAnnotation',
elementType: {
// TODO: T172453752 support complex type annotation for array element
type: paramValue.typeParameters.params[0].type,
}
```
Whereas the TypeScript parser has the more correct behavior of validating the inputs and returning specific outputs. Unfortunately, the return type is also typed here as $FlowFixMe, losing most of the benefits.
```
function getPrimitiveTypeAnnotation(type: string): $FlowFixMe {
switch (type) {
case 'Int32':
return {
type: 'Int32TypeAnnotation',
};
case 'Double':
return {
type: 'DoubleTypeAnnotation',
};
case 'Float':
return {
type: 'FloatTypeAnnotation',
};
case 'TSBooleanKeyword':
return {
type: 'BooleanTypeAnnotation',
};
case 'Stringish':
case 'TSStringKeyword':
return {
type: 'StringTypeAnnotation',
};
default:
throw new Error(`Unknown primitive type "${type}"`);
}
}
```
[DebuggingOverlay](https://fburl.com/code/zfe3ipq7) is abusing this gap in the Flow parser by sticking an Array of Objects in.
```
export type ElementRectangle = {
x: number,
y: number,
width: number,
height: number,
};
...
+highlightElements: (
viewRef: React.ElementRef<DebuggingOverlayNativeComponentType>,
elements: $ReadOnlyArray<ElementRectangle>,
) => void;
...
```
This isn't allowed in the schema, but it seems to fall through the holes of the flow parser and generators.
The resulting schema from Flow is this. Note the GenericTypeAnnotation which isn't allowed to be in the schema.
```
{
"name": "highlightElements",
"optional": false,
"typeAnnotation": {
"type": "FunctionTypeAnnotation",
"params": [
{
"name": "elements",
"optional": false,
"typeAnnotation": {
"type": "ArrayTypeAnnotation",
"elementType": {
"type": "GenericTypeAnnotation"
}
}
}
],
"returnTypeAnnotation": {
"type": "VoidTypeAnnotation"
}
},
```
The TypeScript parser fails with `Error: Unsupported type annotation: GenericTypeAnnotation`.
The generators don't seem to check beyond the ArrayTypeAnnotation so they fall through to generating generic arrays.
```
// ios
elements:(const NSArray *)elements
// android
ReadableArray locations
```
## So how do I fix this?
I think there are a couple of different options here. The key problem is that the Schema types need to represent reality of what can be in the schema.
1. We revert DebuggingOverlay to not use features that aren't supported (I assume nobody would be happy with this, but the change shouldn't have been made in the first place)
2. **(This is the approach taken in this diff)** We add MixedTypeAnnotation to the allowed types in Command arrays and have it generate that and add official support for that to the TypeScript parser as well. That is probably the quickest and easiest approach. It leaves the same type unsafety we have today on the native side.
3. NativeModules seem to have a lot more complex type safety here. They persist the alias type in the schema so that the CompatCheck can check them on changes. And then in C++ they generate structs and RCTConvert functions although for Java and ObjC it looks like they just use the same untyped native code. The matching approach here would be to add `aliasMap` and the whole data to the schema for commands, use that for the compat check, and still generate the same unsafe native code.
```
export type ObjectAlias = {|
x: number,
y: number,
|};
export interface Spec extends TurboModule {
+getAlias: (a: ObjectAlias) => string;
}
```
stores the ObjectAlias in the schema
```
{
"aliasMap": {
"ObjectAlias": {
"type": "ObjectTypeAnnotation",
"properties": [
{
"name": "x",
"optional": false,
"typeAnnotation": {
"type": "NumberTypeAnnotation"
}
},
{
"name": "y",
"optional": false,
"typeAnnotation": {
"type": "NumberTypeAnnotation"
}
},
]
}
},
"spec": {
"methods": [
{
"name": "getAlias",
"optional": false,
"typeAnnotation": {
"type": "FunctionTypeAnnotation",
"returnTypeAnnotation": {
"type": "StringTypeAnnotation"
},
"params": [
{
"name": "a",
"optional": false,
"typeAnnotation": {
"type": "TypeAliasTypeAnnotation",
"name": "ObjectAlias"
}
}
]
}
}
]
}
}
```
and then generates the appropriate structs on the native side and generates [this](https://www.internalfb.com/code/fbsource/[d3ab2f79b377]/xplat/js/react-native-github/packages/react-native-codegen/src/generators/modules/__tests__/__snapshots__/GenerateModuleHObjCpp-test.js.snap?lines=818)
```
Reviewed By: hoxyq
Differential Revision: D67806838
fbshipit-source-id: 31f20455c816fdb6b1a86f8f9d0f6f7d0a452754
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48343
components store unions as 'StringEnumTypeAnnotation' even though it isn't actually a union, it's a literal.
Native Modules store these as 'StringLiteralTypeAnnotation' so this converges those and reuses the same types.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67427656
fbshipit-source-id: e39028114285588584596012d07db40c117b4b94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48318
These structures were the same, but the component side didn't use generics and just had duplicates. Making a base one to be shared.
I need to follow up to this and constrain the types that components allow.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D67371894
fbshipit-source-id: bb1a30fcd0efe6cc567b88bc6f11e7b385bd7c41
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/44521
changelog: [internal]
mapbuffer leaks into every component even though it is only used by 2: Paragraph and TextInput. Let's isolate it only to those two.
To do that, I added a new template prop: usesMapBufferForStateData. It is false by default and only Paragraph and TextInput set it to true.
Reviewed By: christophpurrer
Differential Revision: D56636011
fbshipit-source-id: 4a99e6e68caaf40111b6b7b205854a71f33c5864
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44294
**Problem:**
It was discovered while testing 3 party library, generated member variables in a C++ `struct` in `Props.h` is not initialized.
Also `WithDefault` would not work as well.
(For the problematic case it was a `boolean` but would also apply to other primitive types.)
If there is no default initialization and the component prop is optional and the user of the native component does not set the prop then the variable is never initialized and this is problematic for primitive types in C++ where no initialization results in an undefined behavior.
**Proposed solution:**
(Following C++Core Guideline of [always initialize](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-always).)
Reusing `generatePropsString()` used by `ClassTemplate` to generate props for `StructTemplate` as well.
updated relevant test snapshots.
This change is only concerning the `Props.h` file.
**Changelog:**
[General][Fixed] - fixed `Props.h` created from codegen missing default initializers in C++ `struct`
Reviewed By: cipolleschi
Differential Revision: D56659457
fbshipit-source-id: 0d21ad20c0491a7e8bb718cd3156da65def72f23
Summary:
codegen generates type alias for array enum props with uint32_t which cause wrong overloaded fromRawValue to call at runtime eventually app to terminate
more detailed info at issue https://github.com/facebook/react-native/issues/43821
## Changelog:
[Internal] [Fixed] - Codegen for array enum props
Pull Request resolved: https://github.com/facebook/react-native/pull/44123
Test Plan: TODO
Reviewed By: cipolleschi
Differential Revision: D56414554
Pulled By: dmytrorykun
fbshipit-source-id: 0ec1b65951bc16ff58dd2b119c97a4e3fac2b161
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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42962
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: RSNara
Differential Revision: D53661231
fbshipit-source-id: 28c376fbd08c326f117f8d420485d63e2b4b1241
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42812
There is a way of defining events where you specify additional string type parameter in the EventHandler in the spec. This additional type parameter is an overridden top level event name, that can be completely unrelated to the event handler name.
More context here D16042065.
Let's say we have
```
onLegacyStyleEvent?: ?BubblingEventHandler<LegacyStyleEvent, 'alternativeLegacyName'>
```
This will produce the following entry in the view config:
```
topAlternativeLegacyName: {
phasedRegistrationNames: {
captured: 'onLegacyStyleEventCapture',
bubbled: 'onLegacyStyleEvent'
}
}
```
This means that React expects `topAlternativeLegacyName`.
But the generated EventEmitter looks like this:
```
void RNTMyNativeViewEventEmitter::onLegacyStyleEvent(OnLegacyStyleEvent $event) const {
dispatchEvent("legacyStyleEvent", [$event=std::move($event)](jsi::Runtime &runtime) {
auto $payload = jsi::Object(runtime);
$payload.setProperty(runtime, "string", $event.string);
return $payload;
});
}
```
The native component will emit `legacyStyleEvent` (`topLegacyStyleEvent` after normalization) that React will not be able to handle.
This issue only happens on iOS because Android doesn't use EventEmitter currently.
To address this issue we'll use `paperTopLevelNameDeprecated` for the generated EventEmitters if it is defined.
Changelog: [iOS][Fixed] - Fixed support for event name override in component specs.
Reviewed By: cortinico, mdvacca, cipolleschi
Differential Revision: D53310654
fbshipit-source-id: 018d5b11d8d36e2ecf900b9d8d6fe3e2ed71f80b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42956
In the component codegen system, when the header prefix is an empty string, we generate includes using angle brackets, like this:
```
#include <EventEmitter.h>
```
This fails to compile in buck.
If we instead generate includes using quotations, buck compiles again.
```
#include "EventEmitter.h"
```
So, changes: if the headerPrefix is an empty string, generate includes using quotes.
This is a followup to D51811596.
Changelog: [Internal]
Reviewed By: fkgozali, dmytrorykun
Differential Revision: D53487111
fbshipit-source-id: e90a8b9fd4f8a2a93a0f4ad0ed989af26ad122c5
Summary:
This PR fixes a specific case pointed out by dmytrorykun, where there might be no platform or `deployment_target` specified at all and in that case we assume that this library supports every platform (same as Cocoapods).
## Changelog:
[IOS] [FIXED] - Don't add compiler conditionals when no platforms are specified
Pull Request resolved: https://github.com/facebook/react-native/pull/42867
Test Plan:
Test running codegen when library doesn't specify a `platform`:
```
require 'json'
package = JSON.parse(File.read(File.join(__dir__, 'package.json')))
Pod::Spec.new do |s|
s.name = 'OSSLibraryExample'
s.version = package['version']
s.summary = package['description']
s.description = package['description']
s.homepage = package['homepage']
s.license = package['license']
s.author = 'Meta Platforms, Inc. and its affiliates'
s.source = { :git => package['repository'], :tag => '#{s.version}' }
s.source_files = 'ios/**/*.{h,m,mm,cpp}'
install_modules_dependencies(s)
end
```
Check generated `RCTThirdPartyFabricComponentsProvider`
Reviewed By: cortinico
Differential Revision: D53405625
Pulled By: dmytrorykun
fbshipit-source-id: 0f6917c56b84f0fa29807f516acdbd8d15aa5b46
Summary:
### The problem
1. We have a library that's supported on iOS but doesn't have support for visionOS.
2. We run pod install
3. Codegen runs and generates Code for this library and tries to reference library class in `RCTThirdPartyFabricComponentsProvider`
4. Example:
```objc
Class<RCTComponentViewProtocol> RNCSafeAreaProviderCls(void) __attribute__((used)); // 0
```
This is an issue because the library files are not linked for visionOS platform (because code is linked only for iOS due to pod supporting only iOS).
### Solution
Make codegen take Apple OOT platforms into account by adding compiler macros if the given platform doesn't explicitly support this platform in the native package's podspec file.
Example generated output for library supporting only `ios` and `visionos` in podspec:
I used compiler conditionals because not every platform works the same, and if in the future let's say react-native-visionos were merged upstream compiler conditionals would still work.
Also tvOS uses Xcode targets to differentiate which platform it builds so conditionally adding things to the generated file wouldn't work.
## Changelog:
[IOS] [ADDED] - make codegen take OOT Apple platforms into account
Pull Request resolved: https://github.com/facebook/react-native/pull/42047
Test Plan:
1. Generate a sample app with a template
5. Add third-party library (In my case it was https://github.com/callstack/react-native-slider)
6. Check if generated codegen code includes compiler macros
Reviewed By: cipolleschi
Differential Revision: D52656076
Pulled By: dmytrorykun
fbshipit-source-id: c827f358997c70a3c49f80c55915c28bdab9b97f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42259
At the end of last year, we reduce build fragmentation in iOS making sure that we were always building both architecture.
In the process, we break the semantic od RCt_NEW_ARCH_ENABLED flag, making several libs stop working in one of the two archs.
This change should restore the semantic, so libraries that were using RCT_NEW_ARCH_ENABLED to run conditional code will still work in the same way. While doing so, I also removed the new USE_NEW_ARCH as we don't want unnecessary flags
## CHANGELOG:
[iOS][Fixed] - Bring the old RCT_NEW_ARCH_ENABLED semantic back for compatibility
Reviewed By: cortinico
Differential Revision: D52727792
fbshipit-source-id: e211b10e7885eada83dd2886375575133ca76c8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41956
By default, generated Cxx sources for components all end up in same directory. However the include declarations in them look like this:
```
#include <react/renderer/components/${libraryName}/ShadowNodes.h>
```
And not like this:
```
#include "ShadowNodes.h"
```
This works fine with Buck because it supports header prefixes.
To get this working with CocoaPods we define additional `HEADER_SEARCH_PATHS` for our `React-Codegen` pod.
This approach will not work if we want to generate code at the library level and check in the artifacts. That's because we don't have control over the Podspec there, and can't inject those additional `HEADER_SEARCH_PATHS`.
This diff adds the `headerPrefix` argument to the codegen entry point. It is `react/renderer/components/${libraryName}` by default, but can become empty if we want to generate code at the library level, and don't want to deal with this nested header structure.
*Note:* `RNCodegen` runs all the generators [in a loop](https://github.com/facebook/react-native/blob/main/packages/react-native-codegen/src/generators/RNCodegen.js#L263-L275), assuming that the all have same function signature So I had to add the `headerPrefix` argument to all the generators, even to the ones that don't really need it.
Changelog: [General][Added] - Introduce "headerPrefix" codegen option.
Reviewed By: zeyap
Differential Revision: D51811596
fbshipit-source-id: c5c3e1e571c7c4ea2f5354eb9a7b0df6b917fc0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39540
This simplifies the use of Codegen when creating dev builds of `rn-tester` in the monorepo. It now runs from source for this internal scenario, and this package is now built using the shared monorepo build setup.
Changes:
- Migrate `packages/react-native-codegen` to the shared `yarn build` setup.
- Update package to use `"exports"` field and wrap entry point modules with `babel-register` (NOTE: This is only required for each entry point internally used in the monorepo).
- Fixup small Flow syntax quirks that fail under `hermes-parser`.
- Remove `BuildCodegenCLITask` task from Android build.
- Remove Codegen `build.sh` call from iOS build, use `require.resolve` for `combine-js-to-schema-cli.js` entry point.
Externally significant FYIs:
- `react-native/codegen` is converted to use the `"exports"` field — it should export all `.js` files, as before.
- `codegenPath` is now ignored and marked as deprecated on `ReactExtensions.kt`.
NOTE: TypeScript auto-generation is not yet enabled on this package, since it uses CommonJS `module.exports` syntax (unsupported by `flow-api-translator`).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D49370200
fbshipit-source-id: 992913155169912ea1a3cb24cb26efbd3f783058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37274
With dynamic frameworks, we can't use floating C functions.
The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies.
Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building.
The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded.
**This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks.
This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a
```
+ (void)load
{
[super load];
}
```
method in their ComponentView.
Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules.
## Changelog:
[iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries.
Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual.
Reviewed By: dmytrorykun
Differential Revision: D45605441
fbshipit-source-id: e609fbf6f92fddfbaa676227fde60962d6b0faa4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37145
This diff adds the generation of Array types in events.
It supports the generation of Array of:
- Boolean
- Int32
- Float
- Double
- String
- Objects
- Array
**Note:** This is a first iteration. We could improve the generation further by leveraging the `Bridging` module within React Native.
I'll take a stab at it in a next diff.
## Changelog:
[General][Added] - Generate events with arrays
Reviewed By: cortinico
Differential Revision: D45321685
fbshipit-source-id: 34b05f5501b06714d1fabf1a51cb057af7027f00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37085
changelog: [internal]
Props and event emitter does not need to use JSI_EXPORT. Therefore we can remove include of jsi.h as well.
Reviewed By: cortinico, rshest
Differential Revision: D45274824
fbshipit-source-id: dd756258767f787e49d86dc31e18ce581f444362
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36591
If any of the properties used in event-emitter codegen conflict with `event` or `payload`, the generated code will fail to build, even if this generated code isn't used. Since these are quite common keys, prefix them with `$` (still valid C++) to avoid conflicts.
Changelog: [General][Fixed] Resolved property name conflicts in event-emitter codegen
Reviewed By: cipolleschi
Differential Revision: D44274619
fbshipit-source-id: 45e67850c49e082d8f9b1f85bb632d45a9fd4f1d
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/35984
[Changelog][Internal]
Codegen for props parsing was failing to add a required include for the case when the type is an array of objects, which in turn use non-trivial types.
Something like:
```
export type NativeProps = $ReadOnly<{
...ViewProps,
bounds: $ReadOnlyArray<
$ReadOnly<{
height?: Float,
left?: Float,
top?: Float,
width?: Float,
}>,
>,
}>;
```
would cause compilation errors on C++ side, since the required header for the `Float` conversion wasn't included.
Reviewed By: cipolleschi
Differential Revision: D42781128
fbshipit-source-id: d5b133b931a60e414761db0b3ed09893d3fcc9aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35953
DimensionValue is a reserved prop type that can be a number or string (such as '50%'). On Java, it will get converted to a YogaValue (converter added to this diff); on C++ it will get converted to a YGValue (converter already exists as it's used in Fabric).
Changelog:
[Internal][Added] - Add codegen support for DimensionValue for components
Reviewed By: cipolleschi
Differential Revision: D42650799
fbshipit-source-id: 1d2bc30bbd93837dedbbb4c74f814963c8140957
Summary:
Changelog:
[Internal][Added] - Add support for props of type Array<EdgeInsetsValue>
Reviewed By: christophpurrer
Differential Revision: D42651078
fbshipit-source-id: 3b8683ab199c3d590136cec0e6a67e9e85aaa2c0
Summary:
Changelog: [Internal]
While working on implementing [Event Timing API](https://www.w3.org/TR/event-timing/) I've noticed that there are multiple compiler warnings about unused lambda captures, which are coming from generated C++ code for EventEmitters.
This modifies the codegen so that the corresponding lambda doesn't capture event variable if it's not used in the event handler, thus getting rid of warnings.
Reviewed By: christophpurrer
Differential Revision: D42281899
fbshipit-source-id: 98442bb9f3ce374755188d818a9b2d6a8050bf15
Summary:
i recently made a change to modularize some of our graphics dependencies
i think this codegen will be incorrect now after my diff, so i updated it so we would codegen the correct deps
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D41451842
fbshipit-source-id: 98b5576e9fbd2d693c8bcfeac39d8dfb1b1e0584
Summary:
This diff adds explicit type arguments to polymorphic function calls that do not constrain their types. This codemod will reduce the error burden that will come in a future version of flow.
This specific diff was generated by running:
```
flow codemod annotate-implicit-instantiations --write .
flow --json --pretty | jq '.errors | .[] | .message | .[] | .loc |.source' | sort | uniq | sed -e 's/"//g' | xargs hg revert
hg st -n | xargs grep "generated" | sed -e 's/:.*//g' | xargs hg revert
arc f
```
So these are the codemod results that introduced no new errors and no generated files.
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D40413074
fbshipit-source-id: 42b52719978f1098169662b503dbcfd8cefdad53
