[Integration w/ Existing App] Multiple react-native Applications Design

[yelled3]

I was reading:
https://facebook.github.io/react-native/docs/embedded-app.html#add-rctrootview-to-container-view
and going over the mentioned example:
https://github.com/tjwudi/EmbededReactNativeExample

and I started thinking on having an hybrid application, where some of the features are pure native iOS and other features will each have it's own react-native app (e.i each have it's own RCTRootView)

this kind of design pattern is fairly common when building large web clientside applications.
e.g Marionette.Application: http://marionettejs.com/docs/v2.4.1/marionette.application.html

so a few key questions here are:

• does it makes sense to do so?
• is the current react-native design supports this separation?
• how really incapsulated is a single react-native app (RCTRootView) from another? (will there be any conflicts due to singleton objects, etc...)

Thoughts?

[yelled3]

@vjeux /cc

[revskill10]

Yes, you're free to design your application any way you want. I 've written an article here to show how to integrate ReactView as a subview:
https://github.com/checkraiser/beginning-react-native

[yelled3]

@checkraiser thanks for link but your article is the same as the example I've included and does not address any of my questions :-)

[JohnyDays]

I am implementing this in my app, I'll write here in detail how to do so in code examples when I get to a computer, but it's based on instantiating your own RCTBridges instead of letting RCTRootView do it.
You pass to each RCTBridge instances of the modules you want to be accessible through javascript

[acorscadden]

I'm in the process of implementing something like this. I have an existing app and I'm implementing a new feature by embedding an RCTRootView..

The main issue that I've run into so far is that when an RCTRooView is embedded into a native scrollview, they don't play nicely together. With a fully native implementation, a scrollview will only send touches to its subviews if the scrollview isn't scrolling. TouchableHighlights within the RN view seem to avoid this somehow and it's impossible to drag over the RN view without pressing its buttons.

[JohnyDays]

In my view controller initialization

RCTBridge *bridge = [[RCTBridge alloc] initWithBundleURL:jsCodeLocation 
  moduleProvider:^ NSArray *{
    return @[self];
  } launchOptions:nil];

RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge moduleName: @"SocialWaterfall"];

Intializing the bridge manually allows you to scope each viewController instance to the current RCTRootView, so you can have multiple instances of the same module across different RCTRootViews, without clashing.

If you need some more details tell me.

[vjeux]

@jingc would probably have more context in how we currently deal with this. But as far as I know, we don't have a rock solid answer to this problem and it needs more thinking

[JohnyDays]

Definitely not a rock solid solution, I think with this approach(unless I missed something) it's impossible to pass keyed modules into a bridge, meaning they are always keyed by their class name, making them restricted to 1 instance per class per bridge.

[yelled3]

@JohnyDays few questions;

• shouldn't I pass a weakSelf (of my viewcontroller) to the moduleProvider block?
• have you encountered any issues with this solution?
• can you add some more details regarding the moduleProvider?
  it didn't appear in the official docs - only thing I found about it was in RCTBridge.h

This block can be used to instantiate modules that require additional
init parameters, or additional configuration prior to being used.
The bridge will call this block to instatiate the modules, and will
be responsible for invalidating/releasing them when the bridge is destroyed.
For this reason, the block should always return new module instances, and
module instances should not be shared between bridges.

typedef NSArray *(^RCTBridgeModuleProviderBlock)(void);

and from reading the above docs, this seems like you're kinda misusing the moduleProvider block.

[yelled3]

@vjeux @jingc
can you further share, what are currently the main issues?

[JohnyDays]

The only issue I have found with this approach is that I'm limited to 1 instance per class per bridge, however the standard react export macro approach also limits you in this way.

I'm not sure what a weakSelf is, my obj-c lingo is pretty limited, but I'll check.

I found out about the moduleProvider block by reading the react source code, so this is not a publicly documented API and I recommend it in a use at your own risk kind of way

I'll explain the moduleProvider block with my use case. I have an (already developed without react native) app, this app has a menu, items in the menu can be of different types of view controllers, it was my intention for one of these types to be a react native backed view controller.

One of these is called SocialWaterfallViewController

I first tried exporting using the standard macro, with this approach, upon instantiating an RCTBridge, React automatically instantiates SocialWaterfallViewController and passes it as a module accessible through

require('NativeModules').SocialWaterfallViewController // <SocialWaterfallViewController 0x0002>

Remember I was instantiating the RCTBridge inside of this viewController itself. Why is this a problem? Because now inside javascript, I will have access to <SocialWaterfallViewController 0x0002> instance, while the instance I actually need is <SocialWaterfallViewController 0x0001>, which is the parent of the RCTRootView, and whom exports methods I have to call from javascript.

Using the approach with moduleProvider block, I pass the instance <SocialWaterfallViewController 0x0001> (e.g self) to the RCTBridge, meaning it will prefer that instance instead of instantiating a new one, and javascript now has access to the correct instance.

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[grittymindy]

@JohnyDays I'm using the same approach to pass a specific view controller instance to RCTBridge using moduleProviderBlock. But I have some problem with the lifecycle of the view controller instance. They won't get deallocated when they've already been popped from the navigation controller. Do you have this issue?

[JohnyDays]

If I did have that problem, I didn't notice it. Not currently on the iOS track, sorry I can't help you much :\ . Since the RCTBridges themselves were recycled, I don't understand why that would happen.