Autolinking doesn't work for Components that use c++ state

[grahammendick]

I've tried autolinking in React Native 0.70.0 but it doesn't work for components that use c++ state. These components have interfaceOnly set to true because their ComponentDescriptors have to be hand-written. But your extractComponentDescriptors codegen function explicitly ignores interfaceOnly components.

Please can you tell me how I can get my hand-written ComponentDescriptors included in the generated rncli_registerProviders.

[thymikee]

This sounds like a perfectly valid use case. Right now the componentDescriptors will only be populated by the codegen'd components. For the custom ones we'd need to introduce a new mechanism. Either manually provide extra component descriptors + their #includes or provide a directory where the CLI would grab the files and append to the rncli_registerProviders.

cc @cortinico @troZee

[grahammendick]

Yep, it's a standard use case. If you want to resize a View from native in the new architecture then you have to use c++ state which means an interfaceOnly component. These interfaceOnly components are half codegen'd. React Native codegens the EventEmitters and Props, for example. But it doesn't codegen the ComponentDescriptor, ShadowNodes or State. These are hand-written.

These hand-written files have to make it into the build as well as into the rncli_registerProviders. Also they typically depend on both libreact_render_mapbuffer and libreact_render_imagemanager so can these libraries be added to the android build, please?

[cipolleschi]

Hi everyone, just a couple of considerations. The problem of @grahammendick is due to the fact that Codegen does not support custom state yet. I hope we would be able to do something in that direction at the summit, next week.

That said, manually linking component is an escape hatch we should provide. If it helps, iOS allow that with the RCTComponentViewFactory:: registerComponentViewClass method. Perhaps we can simply expose an API in the rncli to allow for a similar feature.

What do you think?

[grahammendick]

From what I can see, codegen does support custom state via the interfaceOnly attribute. When this is set to true then it codegens the props and event emitters but lets you write custom descriptor, shadow nodes and state. It's the new autolinking that doesn't support the interfaceOnly attribute.

I don't know much about the Android build but @thymikee suggestion of a directory where I could put these files sounds like a good option. It looks to me like there are 2 parts to the whole build on android - the codegen and the cli. I think these hand-written files would have to be included in both parts.

Also, these hand-written files are typically dependent on libreact_render_mapbuffer and libreact_render_imagemanager.

[cortinico]

Please can you tell me how I can get my hand-written ComponentDescriptors included in the generated rncli_registerProviders.

I've just tested Autolinking from 0.70 with a custom component that uses C++ provided state and I can confirm that it works.

If your component has interfaceOnly set to true, we won't be generating some of the implementations. Therefore you'll have to:

• Provide your own C++ implementation for everything (the suggestion is to run the codegen with interfaceOnly set to false once and use this as a blueprint).
• Provide an Android.mk file or a CMakeLists.txt file with custom configuration for your library.
• Update the react-native.config.js to provide your custom configuration as follows:

module.exports = {
  dependency: {
    platforms: {
      android: {
        componentDescriptors: ['UnicornViewComponentDescriptor'],
        androidMkPath: "../cpp/Android.mk"
      },
    },
  },
};

I've worked with @troZee to showcase how this can be done here:
troZee/react-native-cpp-autolinking@5e1b0f2

I've also pushed a change in the CLI that allows to specify a cmakeListsPath as well.

We're looking into extending the codegen to offer state support, so we hope you won't need custom C++ sources at all.

[grahammendick]

I've unmarked it as an answer because it isn't working for interfaceOnly with TurboModules. I'll mark it as an answer once we get to the bottom of the problem

[grahammendick]

@cortinico Ok, I've built an example repo that shows the Android build problem with interfaceOnly components and a TurboModule. The example is built from npx react-native init with no code changes. The only thing I've added is a dependency to my navigation-react-native library which has interfaceOnly components and a TurboModule. If you run npx react-native run-android you'll get error: cannot find symbol public class Material3Module extends NativeMaterial3ModuleSpec {

[grahammendick]

I finally got it working. It took me a loooong time because I had to go through your example line by line to find the problems. Here are 3 key fixes that will hopefully help others avoid the same fate.

1. Added JSI_EXPORT to hand-written cpp interfaces
2. Changed include "Props.h" instead of <react/renderer/components/navigationreactnative/Props.h>, for example, in all the copied over generated cpp files
3. Removed libraries from codegenConfig in package.json

[cortinico]

I'm glad you solved. I was travelling today so I could not look at it.

Added JSI_EXPORT to hand-written cpp interfaces

That's one of the reason we would really love people to use the codegen. It allows us to distribute changes across the whole ecosystem without having to ask every native code to add a macro here and there. That's why having custom state support is so crucial.

[grahammendick]

@cortinico unfortunately it's not working on iOS now. I'm getting the following error where it says there's a redefinition of the EventEmitters. One of the definitions is coming my package's pod and the other is coming from the codegen pod (see 2nd and 3rd images below). Do you know how to fix this or do you want me to make a repo?

One definition

The other definition

[kkafar]

Hi @grahammendick,
starting from example provided by @cortinico I believe I managed to create working setup for react-native-screens that does not require copying all codegened code (and later maintaining it). You can see it here. I did not have to tackle with TurboModules though.

[grahammendick]

Thanks @kkafar. It's kind of you to get in touch. I had the same idea but couldn't get it to work. Yours looks like a work in progress, right?

[kkafar]

It is working setup, currently in review process, but I doubt that much will change.
You can also take a look at this PR from react-native-svg where we also handle TurboModules - there are a lot of unrelated changes, but take a look at commits since 56ca966 (last few commits).

[grahammendick]

Wow, your react-native-screens PR is awesome. Thanks so much. I managed to get it to work after a lot of sweating and cursing. I just couldn't get my hand-written descriptors into the rncli.cpp then I finally noticed you added them to the library.h. That's very clever.

I'm marking yours as the answer because the React Native one doesn't work (double definition error). Even if the React Native one worked, yours requires less manual maintenance (almost no copying over the codegen'ed files).

[grahammendick]

@cortinico @troZee You should update your example repo to follow the react native screens approach.

[grahammendick]

Here's my autolinking PR for anyone who's interested. Thanks again.

@kkafar Just letting you know, I didn't need the following in my CMakesLists.txt.

target_include_directories(
 ${CMAKE_PROJECT_NAME}
 PUBLIC
 ${CMAKE_CURRENT_SOURCE_DIR}
)