Commit Graph

20 Commits

Author SHA1 Message Date
Ramanpreet Nara 3582f43440 Fix relative includes in component codegen (#42956)
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
2024-02-10 14:32:13 -08:00
Dmitry Rykun dae4a11e90 Introduce "headerPrefix" codegen option (#41956)
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
2023-12-20 09:25:05 -08:00
Christoph Purrer 19420b7e68 Use C++17 namespace for compoments (#41791)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41791

Same as https://github.com/facebook/react-native/pull/41771 - but this time for compoments

Changelog: [Internal]

Reviewed By: cortinico

Differential Revision: D51804740

fbshipit-source-id: 87f4db5dabfce4639f16fdcb1b1df0fee338a555
2023-12-05 07:31:57 -08:00
Riccardo Cipolleschi b7add0aadb Always generate an EmptyNativeState (#34754)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34754

This Diff is the second step of enabling the CodeGen to parse and generate a NativeState for the components.

The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.

## Changelog
[General][Added] - Always generate an empty NativeState for Fabric Components

Reviewed By: cortinico

Differential Revision: D39696435

fbshipit-source-id: e24768af78f59696c0b4db009e8065bb5c89316b
2022-09-22 06:41:44 -07:00
Riccardo Cipolleschi 69f8cf14f0 Always generate the EventEmitters (#34750)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34750

This Diff is the first step of enabling the CodeGen  to parse and generate a NativeState for the components.

The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.

To allow the generation of custom `NativeState`, we first have to always generate a `ViewEventEmitter`: that's because the `ConcreteShadowNode` template lists the Generics with this order: `Name`, `Props`, `EventEmitter`, Others...
If we skip the `EventEmitters` and we put the `State`, React Native would think that the State is actually an `EventEmitter` and the build step will fail.

## Changelog
[General][Added] - Always generate a ViewEventEmitter for Fabric Components

Reviewed By: cortinico

Differential Revision: D39509869

fbshipit-source-id: 390cc146ef013baf1ed09d55a0182a5aeb5b9d9e
2022-09-22 06:41:44 -07:00
Nicola Corti f1c614bd0e Build RN Tester with CMake (#33937)
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
2022-06-06 08:07:14 -07:00
Nicola Corti 450967938a Do not include Facebook license on users codegen'd code (#32840)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32840

Closes #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
2022-01-19 08:07:35 -08:00
Andres Suarez 8bd3edec88 Update copyright headers from Facebook to Meta
Reviewed By: aaronabramov

Differential Revision: D33367752

fbshipit-source-id: 4ce94d184485e5ee0a62cf67ad2d3ba16e285c8f
2021-12-30 15:11:21 -08:00
Ramanpreet Nara 3848f48943 Use JavaScript functions for Component templates
Summary:
## Rationale
**Disclaimer**: This is an incremental step towards more maintainable/readable react-native-codegen generators. In the future, we may want to replace these templates/string concat logic with *something better*. But until we decide what that *something better* is, let's at least get rid of all this gross string find/replace.

Benefits of using Function templates over String.prototype.replace.
- **Self-documenting**: Template Functions enumerate/describe their exact data dependencies in their signature. You no longer have to read the template implementation to see what data you need to pass into the template.
- **Improved Readability**: JavaScript syntax highlighting makes it really easy to see where/how the data is inserted into the templates. Also template variables used be prefixed/suffixed with ::, which made things really confusing in C++ code (e.g: wtf is `::_CLASSNAME_::EventEmitter::::_EVENT_NAME_::`?).
- **Simpler Interpolation**: Don't have to worry about .replaceAll vs .replace, or calling these replace functions with regexes or strings.
- **Template Type-safety**: Ensure that the correct data types are passed to the component templates (e.g: flow will complain if you accidentally pass null/undefined when a template expects a string).
- **Template Type-safety**: Ensure that we don't pass in extra data to templates (this diff catches/fixes instances of this error). Ensure that we don't forget to pass in data to the template.
- etc.

After this diff, both our Component and NativeModule generators will be using template functions. This string find/replace exists no more in react-native-codegen.

This is also a very surface-level change. I made no efforts to simplify these templates. Let's take a look at that later, as necessary.

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D32021441

fbshipit-source-id: f8f27069bcbf9d66dcafb7d1411da1f938eb6dcd
2021-11-01 09:00:24 -07:00
Ramanpreet Nara 58c9d8eda7 Fix "Duplicate license header lint error" in Component generators
Summary:
See title.

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D32019151

fbshipit-source-id: aea69a6c032cef1c99cd7641bdc10e730076e781
2021-10-29 10:43:39 -07:00
Erich Graham fa4045e4dd Add ios_assume_nonnull flag to react native codegen library (#31543)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543

Changelog:
[iOS][Added] - Description

When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.

RN native modules are currently generated with *partial* annotations.  This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.

JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.

There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.

Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.

Reviewed By: RSNara

Differential Revision: D28396446

fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
2021-05-20 10:07:37 -07:00
Ramanpreet Nara 9215980471 Remove moduleSpecName
Summary:
All our codegen JavaScript now simply uses libraryName instead of moduleSpecName. In our buck infra, we assign native_module_spec_name to libraryName.

Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D25842696

fbshipit-source-id: efd3af402585f9ad4ff3b593179147eea91cc331
2021-01-07 19:39:56 -08:00
Kevin Gozali 13d9927a48 Codegen: separate Android/Cxx/iOS modules codegen outputs
Summary:
For now, separate the definition of `modules` generator per platform to avoid file output collision. Additionally:
* For Android, produce files under java/ (plus nested subdirs based on packageName) and jni/ (for C++ files) - JavaPoet version already does it
* Allow configuring packageName for Android - JavaPoet version has this
* Avoid tmp directory dance in the CLI script, given the proper modules separation

Changelog: [Internal]

Reviewed By: hramos

Differential Revision: D24410864

fbshipit-source-id: 9bd6bc1d65bec037bfca32ec478f3af50d72e927
2020-10-20 14:11:45 -07:00
Ramanpreet Nara 100c0528f3 Update component generators to follow new ComponentSchema
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).

## Changes
Previously, the "Module" schema could either contain a `components` property, or a `nativeModules` property. The existence of the `components` property was used to determine (1) if the generators would run and (2) filter schemas on which the generators would run. Now, we simply check whether the type of the "Module" schema is `Component`.

Changelog: [Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: PeteTheHeat

Differential Revision: D24236508

fbshipit-source-id: 68cb3f25178b6757c9a4aee767bb6173db4932a6
2020-10-15 22:53:55 -07:00
David Vacca dc7defacef Add @generated tag int Fabric codegen files
Summary:
This diff adds the generated tog to codegen files

changelog: [internal] internal

Reviewed By: fkgozali

Differential Revision: D23117527

fbshipit-source-id: 600013425deeb08321761622e13e7cf9a0f0db38
2020-08-14 12:14:00 -07:00
David Vacca 3093010ea5 move fabric to ReactCommon/react/renderer
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice

Script: P137350694

changelog: [internal] internal refactor

Reviewed By: fkgozali

Differential Revision: D22852139

fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
2020-07-31 13:34:29 -07:00
Michael Bolin 0b9ea60b4f Back out "Upgrade Prettier from 1.17 to 2.0.2."
Differential Revision: D20639755

fbshipit-source-id: 5028563f9cf0527a30b4259daac50cdc03934bfd
2020-03-24 21:47:35 -07:00
Michael Bolin cf44650b3f Upgrade Prettier from 1.17 to 2.0.2.
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html

Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.

Reviewed By: zertosh

Differential Revision: D20636268

fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
2020-03-24 20:24:47 -07:00
Michał Osadnik 0da4612f03 change name convention for modules
Summary:
Following our internal discussion we want to change previously used name convention.
Now it looks like:
```
#import <FBReactNativeTestSpec/FBReactNativeTestSpec.h>
```

Name is a param of `rn_codegen` and `rn_library`. Also, I found it the easiest to move replacing `::_IMPORT_::` into buck rule

Reviewed By: fkgozali

Differential Revision: D16646616

fbshipit-source-id: 2c33c5b4d1c42b0e6f5a42d9a318bd8bda9745f4
2019-08-08 11:18:08 -07:00
Michał Osadnik 96318e438f Split component generator and module generator into separated dirs
Summary: Code generators for modules and components don't have a lot of in common so there's no point to keepo them in the same directory and mix their files.

Reviewed By: rickhanlonii

Differential Revision: D16183434

fbshipit-source-id: b6ee32c6b223e8d6e4bc843b2e111598bee94dc5
2019-07-11 12:58:10 -07:00