[Initialization] Decouple script loading and environment setup from the root view

[ide]

Introduces RCTRootViewController, which handles the controller-appropriate work that RCTRootView was doing. This decouples the view from the script loading and JS environment setup (w/the bridge), which helps ReactKit be less of a framework and more of a library.

One thing that's valuable about moving in this direction is that the more the initialization of the JS environment can be customized (while still providing convenience classes & methods for small apps), the more it encourages established apps to try out ReactKit. I believe this is especially true for apps that use something like Cordova, ex: using the existing Cordova web view's JS context to run React Native and slowly replacing bits of Cordova.

The example apps have been updated and work. On the Facebook side you will need to replace RCTRootView with RCTRootViewController which should be fairly mechanical with VC containment (I hope!)

[ide]

Could I get a code review sometime this week or the next? I know you guys are super busy so when you get a breather is fine. I'm pretty sure the view controller (specifically splitting the environment setup out of RCTRootView) is a step in the right direction and it takes time to rebase on top of the latest commits, so it'd be great if this could be reviewed sometime soon.

[nicklockwood]

Hi James,

Thanks for doing this, and sorry it's gone uncommented for so long.

The thinking behind RCTRootView was that it could be used in places where it's awkward, or non-idiomatic to use a ViewController, such as inside a Table/CollectionViewCell, although I admit that's probably an uncommon scenario.

It may seem odd that a view should be doing so much work, but it's loosely modelled on UIWebView, where you give it a url and it does the rest. Some would consider that a bad pattern, but the separation of responsibility between view/controller in iOS has always been a little wooly IMO anyway. I prefer the model adopted by SpriteKit (and React) where you just have a single hierarchy of nodes that manage their own content.

We're currently working on remodelling RCTRootView to find a more useful division of responsibility. There's nothing wrong with this diff per-se, however it doesn't really address all the problems we're trying to solve, which are:

• we'd like it to be as simple as possible to set up a react view (controller/context/whatever) at any level of an application, whether it's a single view on a screen, a single screen/tab in an existing app, or basically a whole app in its own right.
• we want multiple react views in an app to be able to share a single bridge/executor instance, and to be running the same js application.
• we want to be easily able to pump application-level events such as push notifications into the js context.
• we want to be able to present view-controller based iOS UI elements (e.g UIAlertController) in a non-hacky/fragile way, but without the concept of controllers leaking out into the front-end, JS part of the system.

Having a controller instead of a view as the main entry point helps a little bit with the last of these points, and may in fact end up being part of the solution as a whole, but I'm not sure that it helps at all with the other issues we need to address.

[ide]

Thanks Nick -- appreciate the commentary and it's helpful to know the direction you guys are looking in. If I'm understanding your goals with RCTRootView right, it sounds like you want to separate the JS environment from RCTRootView so that it can manage multiple root views and orchestrate app-wide events.

If you're already far along with the new RCTRootView structure that's fine but just to put an idea out there since this diff might save you guys some work - RCTRootViewController could be renamed RCTEnvironment and would be a plain NSObject subclass. RCTRootViewController doesn't actually use any of UIViewController's features so we can leave that baggage behind and make it easy to embed RCTRootViews anywhere.

Sample code using it might look like:

RCTEnvironment *environment = [[RCTEnvironment alloc] initWithModuleProvider:moduleProvider];
environment.executorClass = [CustomExecutor class];
environment.sourceURL = sourceURL;
RCTRootView *rootView = [environment createRootView:moduleName initialProperties:props];

// Add rootView wherever
[tableCell addSubview:rootView];

// Cleanup
[environment invalidateRootView:rootView];
// or maybe rootView has a backpointer to the enviroment and can clean itself up on
// [rootView invalidate] or when it gets deallocated

Is this more in line with what you're thinking?

[nicklockwood]

That's similar to the model we use internally, where we have a RootView "factory". I was hoping to move away from that pattern though, because it seems very un-iOS like.

I do think we need to move script loading out of the view, but I thought perhaps the bridge could take on that responsibility, since it has effectively become our central DI context/container anyway.

Then you could init a new rootview by passing it a bridge instance, rather than requesting that the environment builds one for you

I don't know though TBH; there's a few different directions to take with it, and I need to work through all the pros and cons of each.

[ide]

Got it, will sit tight for now.

[sahrens]

I think it would make sense to have an option to make a shared bridge and pass it into one or more RCTRootViews.

-Spencer

On Mar 19, 2015, at 10:25 PM, James Ide notifications@github.com wrote:

Got it, will sit tight for now.

—
Reply to this email directly or view it on GitHub.