Codegen Missing Features

[cipolleschi]

In the context of supporting the migration to the New Architecture, we figured out that CodeGen is missing some important features that can be quite helpful for any library developer.

This thread would like to work as an open thread where we can collect the missing features and their use cases. This will help us to:

• Discuss these features
• Prioritize them
• Scope and dimension them
• Decide whether and who will implement them.

To post in the thread, please follow this structure:

---

Missing Feature: < What do you want to be implemented >
How it should work: < Discuss how the feature shoul work and whether it should be supported by both modules and components >
Use Cases: < Describe your use case. Why do you need this? >

[ZihanChen-MSFT]

Missing indexer type in schema..
Missing value type in Promise<T>.
More information in codegen schema for interface inheritance in module.
Missing intersection type for typescript turbo module.
More information in codegen schema for {[key:U]:V}, currently Object is generated.
Missing TypeScript description types for parsers, generators and CodegenSchema.js.

[ZihanChen-MSFT]

facebook/react-native#35812

[cipolleschi]

@troZee, can I hide this discussion as it looks like it is now fixed?

[troZee]

Sure. Thank you for fixing it <3

[ZihanChen-MSFT]

I will take care of that after comming back from christmas vacation

[ZihanChen-MSFT]

facebook/react-native#36037

[troZee]

Tested react-native-codegen version 0.72.0

Missing Feature: Types from another file does not work. Imported types are not recognized by the CodeGen.
How it should work: Imported files should be recognized by the CodeGen.
Use Cases:

import type { CreatePiiTokenParams } from './types/Token';
export interface Spec extends TurboModule {
  initialise(params: CreatePiiTokenParams): Promise<void>;

Keeping all types in one file can make our code unmaintainable. Right now, all types are kept in a separate file to keep the code clean and readable.

[monholm]

This 👍

If the type is only used in a single native module/component, exporting the type from that specific spec file is mostly fine. But as soon as the type is used across multiple native modules/components, the type will have to be duplicated in all the specs using it.

[ZihanChen-MSFT]

I don't think the current architecture is able to support it, it would be a big change.

[cipolleschi]

yeah, this requires some work, which is not straightforward. But we will get there as we understand that it is important to define your types in other files for reuse.

[matinzd]

I tried going through the code and I realized it would be a big change. But it is worth mentioning it here in case we want to start working on it in the future.

[mym0404]

Any update? It seems that TS parser doesn't allow imported object type yet.

[alfonsocj]

Tested react-native-codegen version 0.70.5

Missing Feature: Struct operator == is missing. Xcode complains about an invalid operand when comparing a struct generated by codegen.

Use Cases:

NativeComponent.ts

type ColorFiltersStruct {
colorFilters?: ReadonlyArray<Readonly<{ keypath: string; color: string }>>
}

ComponentView.mm

if(newProps.colorFilters != oldProps.colorFilters) {
...
}

The build fails with an error similar to this one

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator16.1.sdk/usr/include/c++/v1/__algorithm/comp.h:39:71 Invalid operands to binary expression ('const facebook::react::LottieAnimationViewColorFiltersStruct' and 'const facebook::react::LottieAnimationViewColorFiltersStruct')

[monholm]

react-native-codegen = v0.71.5

Missing Feature: Support non-root interface of DirectEventHandler

The following currently works:

interface Frame {
  height: Double;
  width: Double;
}

onPress: DirectEventHandler<Frame>;

interface Frame {
  height: Double;
  width: Double;
}

onPress: DirectEventHandler<{
  someString: string;
  frame: {
    height: Double;
    width: Double;
  };
}>;

While the following throws: Unable to determine event type for "frame": Frame

interface Frame {
  height: Double;
  width: Double;
}

onPress: DirectEventHandler<{
  someString: string;
  frame: Frame;
}>;

Use Cases: Needed for non-trivial event types.

[monholm]

react-native-codegen = v0.71.5

Missing Feature: Support objects in NativeCommands

I might be missing something obvious (and if I do, please don't hesitate to let me know), but it seems impossible to specify any sort of object when using NativeCommands?

The following all fails:

interface NativeCommands {
  animateToRegion: (
    viewRef: React.ElementRef<MyView>,
    region: Object,
  ) => void;
}

Unsupported param type for method "animateToRegion", param "region". Found Object

interface NativeCommands {
  animateToRegion: (
    viewRef: React.ElementRef<MyView>,
    region: UnsafeObject,
  ) => void;
}

Unsupported param type for method "animateToRegion", param "region". Found UnsafeObject

interface NativeCommands {
  animateToRegion: (
    viewRef: React.ElementRef<MyView>,
    region: object,
  ) => void;
}

Unsupported param type for method "animateToRegion", param "region". Found TSObjectKeyword

interface Region {
  latitude: Double;
  longitude: Double;
  latitudeDelta: Double;
  longitudeDelta: Double;
}

interface NativeCommands {
  animateToRegion: (
    viewRef: React.ElementRef<MyView>,
    region: Region,
  ) => void;
}

Unsupported param type for method "animateToRegion", param "region". Found TSInterfaceDeclaration

interface NativeCommands {
  animateToRegion: (
    viewRef: React.ElementRef<MyView>,
    region: {
      latitude: Double;
      longitude: Double;
      latitudeDelta: Double;
      longitudeDelta: Double;
    },
  ) => void;
}

Unsupported param type for method "animateToRegion", param "region". Found TSTypeLiteral

[jerielng]

Chiming in here, as I've noticed that Codegen is incompatible with the following types, unless I'm doing something wrong:

• TSObjectKeyword
• TSUnionType
• generic types

At the moment, I'm working through trial and error to see which parts of our method interfaces are not compatible, but are there are any resources/documentation to fully understand what throws a parser error?

[cipolleschi]

Hi @jerielng, thanks for the question. Could you please specify better which error are you receiving and what you are trying to do?

From your question, it seem like you are using TypeScript. Are you creating a Component or a Module? Unfortunately, the codegen is slightly different among the two, but we are working to unify it.

For what concerns the specific types:

TSObjectKeyword
It could be that it is not supported. For Objects, we support TSTypeReference, TSIntersectionType, TSTypeLiteral in Modules, for example.

TSUnionType

Union of Heterogeneous types is not supported as it is not possible to create a typesafe API in platform code, at the moment. Unions of strings and unions of numbers are supported instead.

generic types

You mean that you want to Codegen a type like type MyGenericTurbomodule<T>? No, this is not supported. I think that we never had that use case internally and therefore never supported it.

Could you share a sample spec with what you are trying to achieve?

but are there are any resources/documentation to fully understand what throws a parser error?

The best resource would be the website. There are also appendices on the typings that you might find useful:

[jerielng]

Thanks for the insight on object types! The appendix has helped, and it sounds like using an object literal is a good workaround.

---

Union types are tricky because there are a couple of ways we're currently using them: 1) as a type alias, 2) as a parameter type, 3) as a return type

For example, if I try to declare a union type as an alias for a number:

export type Month = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12; // This fails the Codegen parser

export interface Spec extends TurboModule {
    setMonth(month: Month);
}

Since this is a union of numbers, is there a reason why this generates the following error:

UnsupportedTypeAnnotationParserError: Module MyGenericTurbomodule: TypeScript type annotation 'TSUnionType' is unsupported in NativeModule specs.

Another case where union type fails is if I want to accept multiple parameter types, like so:

export interface Spec extends TurboModule {
    setValue(key: string, value: number | boolean | string);
}

In this case, I'd like to be able to accept any of these types but would prefer not to use any to restrict which types are accepted.

Similarly, with return types:

export interface Spec extends TurboModule {
    getSubscription(): EmitterSubscription | undefined;
}

[cipolleschi]

Ok, there are multiple things here.

a union type as an alias for a number:

This should work with an enum. Here we intercept the enum and this function produces the enum. I think that this is the right way to model that case, rather than a union.

accept multiple parameter types, like value: number | boolean | string

This is not possible at the moment. Unions of heterogeneous types are a thing in JS, but they cannot be used in a typesafe way in Objective-C and Java. We are discussing internally if we actually do want to support this use case and how to implement it, but, at the moment, the predominance is that type-safety is more important to preserve implementing unsafe union types.

A way to implement a similar API could be the one showcased in this PR, specifically here we add overload which are type safe in the specs and here we implement a function with the union API that then forward the invocation to the right native method.

Similarly, with return types:

This, should work... isn't that the TS way o define optional types? I think that the right way to define it is

export interface Spec extends TurboModule {
    getSubscription(): EmitterSubscription | null | undefined;
}

I don't remember specifically how the optional types are parsed in TypeScript. But you can look into the test fixtures to see what is supported and what not.

We know that it is not ideal, but CodeGen is evolving rapidly: we are going to write proper docs as soon as we find feature completeness and some more stability.

Thank you for the patience.

[oliviermartin]

Generate code without requiring a (dummy) app. Or if the app is really required then write the reason in this page https://github.com/reactwg/react-native-new-architecture/blob/main/docs/turbo-modules.md

Context: I am playing with the Turbo module by following this page: https://github.com/reactwg/react-native-new-architecture/blob/main/docs/turbo-modules.md - I have not created any React Native app in this context so far.
In my (turbo) module, I did npm install to pull the react native module and its codegen script.

node ./node_modules/react-native/scripts/generate-codegen-artifacts.js --help
Usage: generate-codegen-artifacts.js -p [path to app]

Options:
      --help            Show help                                      [boolean]
      --version         Show version number                            [boolean]
  -p, --path            Path to React Native application              [required]
  -o, --outputPath      Path where generated artifacts will be output to

... a React Native application seems to be required for the codegen; Why?

[oliviermartin]

So... Out of curiosity, I have tried to call the codegen in my Turbo module itself with the command: node ./node_modules/react-native/scripts/generate-codegen-artifacts.js --path $PWD --outputPath $PWD/generated
... and it did generate some code without error.

[cortinico]

Generate code without requiring a (dummy) app. Or if the app is really required then write the reason in this page

The app is not required. Where have you read that it's required?
The recommended setup is to have a sample app as auto-linking relies on having an app project though

[oliviermartin]

In the command itself:

node ./node_modules/react-native/scripts/generate-codegen-artifacts.js --help
Usage: generate-codegen-artifacts.js -p [path to app]

Options:
      --help            Show help                                      [boolean]
      --version         Show version number                            [boolean]
  -p, --path            Path to React Native application              [required] <---------- HERE

[cortinico]

That has been recently refactored by @dmytrorykun here:

• Refactor generate-artifacts-executor.js: give library lookup functions more accurate names facebook/react-native#41560

The codegen still needs to have access to the project root (previously called the React Native application) as it needs to do the library lookup of all the dependencies to generate the component descriptor lookup code

[dmytrorykun]

@oliviermartin the codegen guides are currently slightly inconsistent, we'll fix them soon. You can run the codegen for your module without an app. Follow these steps:

1. Configure the codegen for your library.
2. Run the codegen using the codegen CLI.

[hannojg]

Use UnsafeObject as parameter in codegenNativeCommands.

Earlier today I was trying to pass a jsi HostObject to the method of a view command, but found out that thats not possible (while using it as return value seems to be fine):

[hannojg]

Oh, I just realised that using UnsafeObject as return type generates the following protocol:

@protocol RCTFilamentViewViewProtocol <NSObject>
- (void)getSurfaceProvider;
@end

so it seems like using it as report type is also not properly supported yet.

[hannojg]

Okay, just realised that view commands will always return void, so as a second feature request:

Make codegenNativeCommands support different return types than void

[dmytrorykun]

@hannojg I'll copy my answer from a different discussion:

The Command abstraction is a way to tell a native component to do something bypassing the renderer. You should not expect any return value from it. The return value from a command generally may depend on many things other than component itself. This makes such component non-composable. This breaks one of React's fundamental principles. This is also the reason why it only accepts primitive types. We may add some more capabilities in the future, but there are currently no plans for that.

I would recommend to try finding a way to implement this behaviour using Native Modules.