New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TurboModule (NativeModules Re-architecture) Discussions #40

Open
fkgozali opened this Issue Oct 12, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@fkgozali

fkgozali commented Oct 12, 2018

Introduction

This is a place for discussions around the upcoming "TurboModule" feature.

Terminology

  • JSI: JavaScript Interface
  • TurboModule: re-architecture of NativeModules, using JSI
  • Fabric: the UI layer re-architecture, to take full advantage of concurrent React architecture. Please visit #4 instead

Available Materials

At ReactConf 2018 @axe-fb did a talk about React Native's New Architecture, which also explains the 3 concepts above: JSI, Fabric, TurboModule.

Q&A

This is also a place for questions related to this effort and its direction.

@fkgozali

This comment has been minimized.

fkgozali commented Oct 12, 2018

cc @kelset - wanna label this one with "Transparency"? I don't have access looks like.

cc @axe-fb

@empyrical

This comment was marked as off-topic.

Member

empyrical commented Oct 29, 2018

Not sure if native components would get covered by this. But, I wonder, could lazy loading native components take advantage of Suspense? Something like this:

const RCTWebView = lazy(() => lazyRequireNativeComponent('RNCUIWebView'));

Then, in the wrapper component:

<Suspense fallback={this.props.renderPlaceholder()}>
  <RCTWebView />
</Suspense>

The placeholder view could be specified by the developer as a prop.

This may be a little hacky, however, since it expects to be only used with a promise returned from import().

So the promise returned by this hypothetical lazyRequireNativeComponent would need to be an object like: { default: [the native component] }

@TheSavior

This comment has been minimized.

TheSavior commented Oct 29, 2018

@empyrical, this isn’t related to turbomodules, but rather one of the other projects I’m working on. This won’t need to be lazy because requireNativeComponent won’t exist and the only work that will be done is returning the string “RCTView”. There will be no round trips to native so it won’t provide value to make this async.

@fkgozali fkgozali changed the title from TurboModule Discussions to TurboModule (NativeModules Re-architecture) Discussions Nov 2, 2018

@tomduncalf

This comment has been minimized.

tomduncalf commented Nov 17, 2018

Does this proposal (and related parts such as JSI) mean C++ native modules will become a first class, documented citizen of the RN universe?

That would be awesome, I’m doing a lot of work in this area and most of it had to be figured out by reverse engineering/trial and error.

@fkgozali

This comment has been minimized.

fkgozali commented Nov 17, 2018

Does this proposal (and related parts such as JSI) mean C++ native modules will become a first class, documented citizen of the RN universe?

Depends on what you meant by first class citizen. You can already build C++ class that talks directly to the VM via JSI's HostObject - all JSI code is already in master: https://github.com/facebook/react-native/blob/bf2500e38ec06d2de501c5a3737e396fe43d1fae/ReactCommon/jsi/jsi.h#L80

An example consumer is https://github.com/facebook/react-native/blob/94d49e544d10d0039a1178dc97533e96a4354198/ReactCommon/fabric/uimanager/UIManagerBinding.h

We plan to build a thin C++ wrapper on top of this direct access to HostObject to make the binding slightly easier in the future, but the first focus will be ObjC/Java modules. Documentation will come when they are all ready and stable. So yes, C++ modules will become first class in this angle.

@tomduncalf

This comment has been minimized.

tomduncalf commented Nov 19, 2018

This is really interesting, thanks for the pointers. So far we've been working with CxxModule, looks like this could be a cleaner alternative!

Will have a proper look into it when time allows, we are doing some pretty interesting stuff with C++/React Native integration which pushes it fairly hard and could make a good test case for some of this stuff, so if you'd be interested in discussing in more detail please feel free to get in touch (details in Github bio)!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment