Summary:
Flow and TypeScript are two very similar programming languages. They are both recognizable as inputs for turbo module codegen. It is reasonable to require equivalent Flow and TypeScript turbo module definition generates the same output.
I add some test cases to ensure this. Glad that no functional inconsistency is found here.
## Changelog
[General] [Changed] - codegen: ensure equivalent Flow and TypeScript TM definition generates the same output
Pull Request resolved: https://github.com/facebook/react-native/pull/34251
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: dmitryrykun
Differential Revision: D38116756
Pulled By: cipolleschi
fbshipit-source-id: 476adbd171a35813923f2020c826d21b1fc2eeed
Summary:
Turbo module codegen for component parse `readonly T[]` and `readonly Object[][]` incorrectly. In this change, it is fixed, with necessary test cases added.
## Changelog
[General] [Added] - Support TypeScript array types for turbo module (component only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34216
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: sammy-SC
Differential Revision: D37953004
Pulled By: cipolleschi
fbshipit-source-id: b71ea35eb9c4bd5dc41130f1dcf9201704ec298e
Summary:
According Flow's document, a maybe type of T means `T | null | undefined`, instead of `T | null | void`.
I think keeping TypeScript and Flow being consistent to each other is better.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Changed] - Accept TypeScript type `T | null | undefined` as a maybe type of T in turbo module.
Pull Request resolved: https://github.com/facebook/react-native/pull/34158
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: yungsters
Differential Revision: D37731169
Pulled By: philIip
fbshipit-source-id: b6d9b7e8991f60e12c1004bed5b937b34fb02c47
Summary:
Turbo module codegen supports arrays in both Flow and TypeScript, but it only recognize `Array<T>` and `ReadonlyArray<T>` in TypeScript.
In this change, `T[]` and `readonly T[]` are made recognizable in codegen.
## Changelog
[General] [Added] - Support TypeScript array types for turbo module (module only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34183
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: lunaleaps
Differential Revision: D37812638
Pulled By: cipolleschi
fbshipit-source-id: d63b0585497a43c274d50e1877baab5d1cc3f8fa
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: bradzacher
Differential Revision: D37363351
fbshipit-source-id: a9d3df7db6f9d094ac2ce81aae1f3ab4f62b243a
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37360113
fbshipit-source-id: 870bcfe680542b3861fefbaf372db0ae8b32cbf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34015
I noticed this was a very slow part of my build because each instance of the binary would run its own yarn install. Instead use the yarn_workspace approach to share a single yarn setup.
Changelog: [Internal]
Reviewed By: IanChilds
Differential Revision: D37178005
fbshipit-source-id: cba51e168c5a2f2ee6468acb8c144db4ad352d95
Summary:
This fixes an issue in the C++ TurboModule codegen where optional return types would result in a compiler error because they were not being defaulted to `null` when converting to `jsi::Value`.
Changelog:
Internal
Reviewed By: javache
Differential Revision: D36989312
fbshipit-source-id: 525f9ce7a5638ba5a655fa69ba9647978030ab0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33937
This moves the build of RNTester from Unix Make to CMake
This will serve as a blueprint for users that are looking into using CMake end-to-end in their buildls.
In order to make this possible I had to:
* Add an `Android-prebuilt.cmake` file that works similar to the `Android-prebuilt.mk` for feeding prebuilt .so files to the consumer build.
* Update the codegen to use `JSI_EXPORT` on several objects/classes as CMake has stricter visibility rules than Make
* Update the sample native module in `nativemodule/samples/platform/android/` to use CMake instead of Make
Changelog:
[Internal] [Changed] - Build RN Tester with CMake
Reviewed By: cipolleschi
Differential Revision: D36760309
fbshipit-source-id: b99449a4b824b6c0064e833d4bcd5969b141df70
Summary:
This fixes an issue where nullability was lost on readonly types in TurboModules specs. The "outside" nullability would be ignored in favor of only respecting the "inside" nullability (i.e. `?$ReadOnly<{}>` vs `$ReadOnly<?{}>`). It now ensure either is propagated correctly.
Changelog:
[General][Fixed] Fix nullability lost on readonly types in TurboModule specs
Reviewed By: RSNara
Differential Revision: D36615346
fbshipit-source-id: 42408d9298703f4c382657f573480d2574d6c973
Summary:
There are cases where we want to pass arbitrary types to a TurboModule, which may then handle the values appropriately, but we haven't supported this use case. Since C++ TurboModules can accept any `jsi::Value` (unlike Java/ObjC) and we have real-world need for this (otherwise we must require JSON serialization), this now allows `mixed` (`unknown` in TypeScript) for C++-only TurboModules.
Changelog:
[General][Added] C++ TurboModule methods can now use mixed types
Reviewed By: RSNara
Differential Revision: D36611299
fbshipit-source-id: bbf29dfcc6aed67e213bb3eab06537c18c7db1fe
Summary:
Codegen a static field for every caller of `invokeJavaMethod` to cache the jmethodID that should be used for the method, which saves us a string-based name lookup at invocation time.
Changelog: [internal]
Reviewed By: genkikondo
Differential Revision: D36376056
fbshipit-source-id: 298430746a8f25a5337aba05b56876ba789e2344
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33773
I noticed this was a very slow part of my build because each instance of the binary would run its own yarn install. Instead use the yarn_workspace approach to share a single yarn setup.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D36164350
fbshipit-source-id: 5290587010fe6021b758bda98bf01995fdf14acd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33729
This PR addresses [this comment](https://www.internalfb.com/diff/D35820848?dst_version_fbid=496290878846487&transaction_fbid=355967423221044).
It makes the CodeGen to the `outputDir` as base directory for the codegen.
Finally, it updates the unit tests accordingly.
## Changelog
[iOS][Changed] - use `outputDir` as base directory for the codegen and remove the possibility to customize the intermediate path. The generated code requires specific paths in the `#include` directive.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35935282
fbshipit-source-id: a9ad4e296efb042cf34b20db5eebb59614beb5f6
Summary:
This Diff introduces some changes in the CodeGen to properly generate the types in the right folder.
## Issue
The codegen on iOS defines the output folder once, before creating the generated code.
When the code we have to generate is just a TurboModule (TM) or a Fabric Component (FC), this mechanism works properly.
However, if a library has to generate both TM and FC, actually using the library type `all`, all the code is generated using the TurboModules' output folder.
(**Note:** Android only works in this way)
This generates invalid code because all the FC's `#import` directives assumes that the code is generated in the FC output path which, in this case, is not.
## Solution
The adopted solution moves the responsibility to decide where the files has to be generated to the CodeGen step instead of in the preparatory phases.
The two paths are precomputed in the `generate-artifacts.js` script (the entry point for the CodeGen) and they are passed to all the scripts that requires them.
Once they reach the `RNCodegen.js` file, the generators creates the files and save them in the proper paths.
## Changelog
[iOS][Changed] - CodeGen now supports the `"all"` library type.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35820848
fbshipit-source-id: ce7f5393936e2ae17f8b2c970f6a011d27f641f2
Summary:
We're adding a native module that returns a Nullable type. This makes the Java spec and the implementation to be the same.
Changelog:
[Android][Added] - Generate `Nullable` for optional objects and arrays in module codegen.
Reviewed By: yungsters
Differential Revision: D35651333
fbshipit-source-id: d73c87340e33cf79831915ce6892e457ef369175
Summary:
This adds the option for a TurboModule spec to use a "Cxx" suffix to unblock additional capabilities. This extends the pattern where TurboModules can have an "Android" or "IOS" suffix to exclude codegen for the other platform. When in `cxxOnly` mode, the parser will allow function return types (and additional features will be added over time).
Changelog:
[General][Added] C++ TurboModule methods can return functions
Reviewed By: christophpurrer
Differential Revision: D35364346
fbshipit-source-id: 768eb0ec2a1cbe3e458466064247d7e7f01135ff
Summary:
Update C++ TurboModule codegen to wrap nullable types in `std::optional` whereas before the conversion would cause a crash.
Changelog:
Internal
Reviewed By: mdvacca, nlutsenko
Differential Revision: D35299708
fbshipit-source-id: 7daa50fe8b16879c5b3a55a633aa3f724dc5be30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33518
Changelog: [Internal]
When building with buck2, `setup_env_vars.sh` cannot be found. exporting setup_env_vars.sh and adding it as a dep to `write_to_json` fixes it.
Reviewed By: d16r
Differential Revision: D35188154
fbshipit-source-id: e1e1be4c83a57e443a181efaf1af3e6c8e6452f9
Summary:
In the previous template, configure depends was placed after the globbing expression, causing CMake warning.
Changelog: [Internal] - Correct globbing for CMake config in the codegen
Reviewed By: cortinico
Differential Revision: D35044874
fbshipit-source-id: 4f022bfaaec3a84141f4be7de96c56a545639e56
Summary:
Generates `CMakeLists.txt` for the codegen the same way as we generate Android.mk
Changelog: [Internal] - CMakeLists.txt for codegen targets
Reviewed By: cortinico
Differential Revision: D34821864
fbshipit-source-id: 0cbe7a450a4a064e2285890253ae152fb03267c2
Summary:
Rearranges folly_futures configuration into a static library only required for `hermes-inspector` + `folly_runtime` which merges `folly_json` and mutex-related implementations `folly_futures` was used for. As `hermes-executor-debug` is removed by `vmCleanup` configurations later, it allows to shave additional 300KB from the release APK size.
Changelog: [Internal] - Rearrange folly build to reduce APK size
Reviewed By: cortinico
Differential Revision: D34342514
fbshipit-source-id: b646680343e6b9a7674019506b87b96f6007caf2
Summary:
This adds the *option* for C++ TurboModules to use a `*CxxSpec<T>` base class that extends the existing (and unchanged) corresponding `*CxxSpecJSI` base class with code-generated methods that use `bridging::calFromJs` to safely convert types between JSI and C++. If a type conversion cannot be made, then it will fail to compile.
Changelog:
[General][Added] - Automatic type conversions for C++ TurboModules
Reviewed By: christophpurrer
Differential Revision: D34780512
fbshipit-source-id: 58b34533c40652db8e3aea43804ceb73bcbe97a5
Summary:
Since the generated functions move JSI arguments as rvalues into these methods, using const lvaue references doesn't provide any benefit, and in fact hinders our ability to *move* arguments somewhere else and instead requires having to confusingly copy them instead (which JSI makes more difficult).
Changelog:
Internal
Reviewed By: nlutsenko
Differential Revision: D34704455
fbshipit-source-id: 520a358d8a7adeb848e7d7eb204f7154f8f4b58d
Summary:
This moves the `indent` function into a `Utils` module so it can be also used to properly indent the abstract methods declarations in a C++ TurboModule spec.
Changelog:
Internal
Reviewed By: nlutsenko
Differential Revision: D34704456
fbshipit-source-id: 88a3a672e4860927b5dd1f5107f40da7b5a83e51
Summary:
The `get*` methods will assert and thus crash if JS passes a value by the wrong type. Although we have type checking, we should strive to never crash the app if an incorrect value slips by. The `as*` variants will throw an error back into JS instead.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D34630900
fbshipit-source-id: 5ec55ca08ca7a1f43b2d9bfbb1d4e6fa89146e12
Summary:
The props generator assumes that Props are used only on iOS. (i.e: the generator doesn't generate the props code if the iOS platform is excluded). However, Props are also used on Android. So, this diff makes us generate Props for all platforms.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D34559900
fbshipit-source-id: 0c25835dd57aa55a094152c147a9f952b9bc6850
Summary:
This adjusts the previously unused (but fully working!) `rn_codegen_cxx_modules` rule to be consistent with the other codegen rules and calls it from the `rn_codegen` with the "JSI" suffix to not conflict with the other rules, and to match the convention established by hand-written C++ TurboModules.
Changelog:
Internal
Reviewed By: RSNara
Differential Revision: D34451208
fbshipit-source-id: 4d779b068dfa4f7fd73fd3bca354fffe86d01f73
Summary:
Changelog: [Internal]
* Rename DummyUIManager to BridgelessUIManager
* Cleanup `RCTVirtualText` & `RCTShimmeringView` since the native changes from T107747313 are already in production, so these two will components always return a viewConfig in prod.
- `console.error` when deprecated Bridge UIManager method are being accessed.
- Make sure new BridgelessUIManager.js has the same method definition as [NativeUIManager.js](https://www.internalfb.com/code/fbsource/[e80c98b816183dcdfde1e81de01ba99aa6e30ed2]/xplat/js/react-native-github/Libraries/ReactNative/NativeUIManager.js?lines=15)
Reviewed By: RSNara
Differential Revision: D34203081
fbshipit-source-id: 99aafc2372b118d0c8cc41f7376e136dabae9bd5
Summary:
That's a really nit change, but when we moved the Makefile deps to be on separate
lines, we havent' done the same for the codegen. Here I'm doing it.
Changelog:
[Internal] [Changed] - Place Android.mk dependencies on separate lines for codegen
Reviewed By: ShikaSD
Differential Revision: D34144715
fbshipit-source-id: be9d5fb75b6b93c0b2bb479145053ae6f201e1fc
Summary:
I was trying to add an object property to my ViewManager and got a really opaque error (and I almost thought Objects weren't supported by the codegen) until I realized it expected the object to wrapped in a $ReadOnly type.
Changelog: [Internal] Improved error in codegen
Reviewed By: mdvacca
Differential Revision: D34006557
fbshipit-source-id: b3ab15a40cb66fdcd377f4e68df92060498e8e7f
Summary:
Changelog: [Internal]
Since DummyUIManager.getViewManagerConfig() & hasViewManagerConfig() are the same, it's safe to ship this before the native changes in this stack lands.
Reviewed By: RSNara
Differential Revision: D33832926
fbshipit-source-id: c0f0a169d02397e0f9125bb45d95d395c8bbc492
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32840Closes#31516
I've cherry-picked the original PR that had merge conficts + updated all
the headers as the one for the TurboModule generators were not handled.
Original Commit Message from acoates
The codegen generates a Facebook copyright notice at the top of the generated files.
While this might make sense on the core files, this codegen will be run on external components too.
The notice also refers to a LICENSE file in the root of this project, which might not be there if this is run on another project.
I did a quick look at some of the codegen that we ship within windows dev tools, and it looks like we normally just have comments
saying the file was codegen'd and so the file shouldn't be manually edited.
Open to suggestions on what the comment header should say.
Changelog:
[General] [Changed] - Do not include Facebook license on users codegen'd code
Reviewed By: ShikaSD
Differential Revision: D33455176
fbshipit-source-id: b247e72efb242e79d99b388c80e4126633e5234d
Summary:
## Context
Inside native ViewConfigs, events are declared using these bubbling/direct EventType maps:
```
{
uiViewClassName: '...',
bubblingEventTypes: {
topFoo: {
registrationName: "onFoo"
}
},
directEventTypes: {},
validAttributes: {
},
}
```
**Pattern:** Note that the top name (i.e: topFoo) is just the registration name (i.e: onFoo) but with "on" replaced with "top".
On Android, registration names and top names don't have to follow this pattern. The top name can be **anything.** See ReactionsDockView:
https://www.internalfb.com/code/fbsource/[c430d46ed69a03a9d9f40cefa335a6d8bb92f8ec]/fbandroid/java/com/facebook/feedback/reactions/ui/overlay/react/ReactionsDockViewManager.java?lines=26-28%2C32-34%2C38
Here, ReactionDismissedEvent.EVENT_NAME is "topDismiss"
https://www.internalfb.com/code/fbsource/[c9f92314a5c46e561a831100dab82164808b05d0]/fbandroid/java/com/facebook/feedback/reactions/ui/overlay/react/ReactionDismissedEvent.java?lines=10-11%2C26
And so to provide you the flexibility to specify a custom topName, the codegen supports a customTopName in the direct/bubbling event types:
```
onDismissWithFeedbackReaction: DirectEventHandler<Event, 'topDismiss'>,
```
This generates the two bubbling event type entries in ReactionsDockView:
```
{
uiViewClassName: '...',
bubblingEventTypes: {
// custom top name
topDismiss: {
registrationName: "onDismissWithFeedbackReaction"
},
// what the top name should actually be
topDismissWithFeedbackReaction: {
registrationName: "onDismissWithFeedbackReaction"
}
},
directEventTypes: {},
validAttributes: {
},
}
```
**The Problem:** The entry created for "topDismissWithFeedbackReaction" is not necessary. This additional entry creates a discrepancy between ReactionsDockView's static ViewConfig and native ViewConfig. Therefore, this diff removes the second unnecessary entry.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D33418730
fbshipit-source-id: 3988ff6906ad1b2e1ef988a19c64d1e042381ab1
Summary:
With SVC enabled for codegenNativeComponent, use `UIManager.hasViewManagerConfig(viewManagerName)` instead of `UIManager.getViewManagerConfig(viewManagerName)` to check for whether the native component is in the app BUCK binary.
This is safe because `global.__fbStaticViewConfig` is gated with MC, and the purpose of SVCs is to stop using `getViewManagerConfig` to get view configs from the Paper view managers. Currently no QEs have SVCs enabled.
Changelog:
[Fabric][JS] For codegenNativeComponent, with SVC enabled, use UIManager hasViewManagerConfig instead of getViewManagerConfig
Reviewed By: RSNara
Differential Revision: D33511365
fbshipit-source-id: 58c7020903137e2b5c80ef34a956be04de51628b
Summary:
For every direct and bubbling event, RCTComponentData (iOS-only) creates a {eventName}: true entry in the component's ViewConfig validAttributes. This entry is unnecessary, and creates a discrepancy between ViewConfigs on iOS vs Android.
This diff removes this entry for all events to:
1. Reduce bloat in native ViewConfigs
2. Create consistency betweeen Android and iOS.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D33303950
fbshipit-source-id: 870c8a2a6d41156ac89bd8554eb09f292bb6108e
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Zihan Chen (MSFT)
Pieter Vanderwerff
Dustin Shahidehpour
Scott Kyle
Nicola Corti
Pieter De Baets
Anandraj Govindan
Riccardo Cipolleschi
George Zahariev
John Wang
Wei Han
Erich Graham
Andrei Shikov
Ramanpreet Nara
Paige Sun
Andres Suarez
Ian Childs
Luna Wei
Kevin Gozali