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/52239
Add `toDynamic` conversion function for `EdgeInset` which allowed for removing the custom conversion implemented for the `ViewProps`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234069
fbshipit-source-id: 3aecad8a6d78468f0056167fa1523ccdfb68f369
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/51880
Updates the `sort-imports` lint rule.
The main change is that it enforces newlines after the last import statement.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D76149902
fbshipit-source-id: 928871655c5de0613b18334d6fc0d71b3a971a18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51806
Correct the type of args, which is always non-null. This is backwards-compatible as subclasses can override this method with a more permissive nullable type and still be substitutable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75869317
fbshipit-source-id: 8f6c9119140794447eca55be24483a35450d7bb6
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/51642
This diff asserts that ImageRequest won't be used as prop type
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75469453
fbshipit-source-id: e9e46bc8806e00c104b76825445fe72779106220
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51524
Links in error suppressions will point to the announcement post in Flow FYI.
Changelog: [Internal]
drop-conflicts
Reviewed By: marcoww6
Differential Revision: D75188177
fbshipit-source-id: 27ea1fbee848e9371e679cf423e30bc9608edea0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51185
Was running into issues with split Android ParagraphState, because a lot of code is tied to `#ifdef ANDROID`, which also builds for react-native-cxx.
This does that spliitting, and also introduces `RN_SERIALIZABLE_STATE` to replace previous ANDROID checks related to state serialization, so we can cofine that to just the Android platform. These changes are dependent on each other.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D74374376
fbshipit-source-id: ffb246ea2e16773f85de12209f2d88a95f8bb792
Summary:
The `Object.assign` support is [inherently unsound](https://github.com/facebook/flow/issues/3392), carries a lot of tech debt, and we want to error on them.
This diff pre-suppresses errors that will be added in the next version of Flow, to make the next release easier.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D73963639
fbshipit-source-id: ebefc82c123588eb0b72ab48a24e45c42be33267
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/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/49349
Follow-up on D69454101 to add more test coverage for `$ReadOnlyArray<UnsafeMixed>` as a component prop. The new type was missing from the CodegenSchema, which revealed some gaps in tests.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D69488035
fbshipit-source-id: 19895e55e5ec4d89a790f1c388de9eea025a316c
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:
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
Nick Lefever
Tim Yung
Pieter De Baets
David Vacca
Panos Vekris
Nick Gerleman
Sam Zhou
Jakub Grzywacz
Phil Pluckthun
Nicola Corti
Iwo Plaza
Rayner Kristanto
Eli White
Tom Van Laerhoven
Thomas Nardone
Samuel Susla
Alan Lee
Nizam
Dmitry Rykun
Ramanpreet Nara