Codegen Missing Features #91
-
|
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:
To post in the thread, please follow this structure: Missing Feature: < What do you want to be implemented > |
Beta Was this translation helpful? Give feedback.
Replies: 12 comments 27 replies
-
|
|
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
Beta Was this translation helpful? Give feedback.
-
|
@troZee, can I hide this discussion as it looks like it is now fixed? |
Beta Was this translation helpful? Give feedback.
-
|
Sure. Thank you for fixing it <3 |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
I will take care of that after comming back from christmas vacation |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Tested Missing Feature: Types from another file does not work. Imported types are not recognized by the CodeGen. 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. |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this? @cipolleschi |
Beta Was this translation helpful? Give feedback.
-
|
No updates yet on this, I'm sorry. I do understand that the experience is not optimal, but there is currently a workaround for this problem and we have other parts of the New Architecture that needs to be fixed more urgently. I really hope that we can carve some time in the future to improve the Codegen experience. |
Beta Was this translation helpful? Give feedback.
-
|
Any update on this yet?
|
Beta Was this translation helpful? Give feedback.
-
|
At least it should be explained in the official documentation. I was confused about this for a long time before I finally found this discussion. |
Beta Was this translation helpful? Give feedback.
-
You can define the types that you need within the spec for the Module or the Component. We know it's not ideal to duplicate the types, but implementing parsing the import and generating the type in a separate header/implementation is not trivial work and it will be a big breaking changes: we will break all the libraries that have been written so far. |
Beta Was this translation helpful? Give feedback.
-
|
Tested Missing Feature: Struct operator 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 |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
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: interface Frame {
height: Double;
width: Double;
}
onPress: DirectEventHandler<{
someString: string;
frame: Frame;
}>;Use Cases: Needed for non-trivial event types. |
Beta Was this translation helpful? Give feedback.
-
|
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;
}
interface NativeCommands {
animateToRegion: (
viewRef: React.ElementRef<MyView>,
region: UnsafeObject,
) => void;
}
interface NativeCommands {
animateToRegion: (
viewRef: React.ElementRef<MyView>,
region: object,
) => void;
}
interface Region {
latitude: Double;
longitude: Double;
latitudeDelta: Double;
longitudeDelta: Double;
}
interface NativeCommands {
animateToRegion: (
viewRef: React.ElementRef<MyView>,
region: Region,
) => void;
}
interface NativeCommands {
animateToRegion: (
viewRef: React.ElementRef<MyView>,
region: {
latitude: Double;
longitude: Double;
latitudeDelta: Double;
longitudeDelta: Double;
},
) => void;
}
|
Beta Was this translation helpful? Give feedback.
-
|
Chiming in here, as I've noticed that Codegen is incompatible with the following types, unless I'm doing something wrong:
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? |
Beta Was this translation helpful? Give feedback.
-
|
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:
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.
You mean that you want to Codegen a type like Could you share a sample spec with what you are trying to achieve?
The best resource would be the website. There are also appendices on the typings that you might find useful: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the insight on 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: Since this is a union of numbers, is there a reason why this generates the following error: Another case where union type fails is if I want to accept multiple parameter types, like so: In this case, I'd like to be able to accept any of these types but would prefer not to use Similarly, with return types: |
Beta Was this translation helpful? Give feedback.
-
|
Ok, there are multiple things here.
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.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. ... a React Native application seems to be required for the codegen; Why? |
Beta Was this translation helpful? Give feedback.
-
|
So... Out of curiosity, I have tried to call the codegen in my Turbo module itself with the command: |
Beta Was this translation helpful? Give feedback.
-
The app is not required. Where have you read that it's required? |
Beta Was this translation helpful? Give feedback.
-
|
In the command itself: |
Beta Was this translation helpful? Give feedback.
-
|
That has been recently refactored by @dmytrorykun here: 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 |
Beta Was this translation helpful? Give feedback.
-
|
@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:
|
Beta Was this translation helpful? Give feedback.
-
|
Use 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):
|
Beta Was this translation helpful? Give feedback.
-
|
Oh, I just realised that using @protocol RCTFilamentViewViewProtocol <NSObject>
- (void)getSurfaceProvider;
@endso it seems like using it as report type is also not properly supported yet. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, just realised that view commands will always return Make |
Beta Was this translation helpful? Give feedback.
-
|
@hannojg I'll copy my answer from a different discussion: The I would recommend to try finding a way to implement this behaviour using Native Modules. |
Beta Was this translation helpful? Give feedback.
-
|
Currently, when I tested with version 0.76.5(the latest version is 0.79.x but it would be in similar situation), here are the limitations I found when working with React Native Turbo Modules codegen:
|
Beta Was this translation helpful? Give feedback.
@hannojg I'll copy my answer from a different discussion:
The
Commandabstraction 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.