[Bridge] Pass __fbBatchedBridgeConfig into the bundle instead of making it global

[ide]

This is to reduce globals and encourage scoping. A specific approach I have in mind is to make the bundle produce a function that takes the bridge config as an argument:

(function(batchedBridgeConfig) {
// current bundle code here
});
// source map stuff

And when setting up ReactKit:

// get the js context from the executor -- API for this needs to be thought out
[[context evaluateScript:bundleScriptString] invokeWithArguments:@[configObject]]

Then the global goes away and you don't need -[RCTJavaScriptExecutor injectJSONText:asGlobalObjectNamed:callback:] either!

[frantic]

I think it's a very clever idea and I like reducing RCTJavaScriptExecutor protocol. However, the code in the bundle has to define a global require function that will be used by ObjC to invoke JS methods. Also there are benefits for the existing model, for example Chrome debugger integration (not in the oss repo yet) that runs the JS code in a Chrome page. The app bundle in this case is loaded via <script> tag instead of being passed via websockets.

[ide]

Could the JS application engine be set up by passing in a global object? For example:

(function(global) {
  // Make require.js use "global", which passes it to all of the module factory functions.
  // require.js also sets "global.require", "global.requireLazy", etc...
});

From the native side, the application engine is initialized like:

// Create a "global" object. May need to have it act as a proxy to the real global object
// and would need to write a little more code for that.
JSValue *reactGlobal = [JSValue valueWithNewObjectInContext:context];
reactGlobal[@"__fbBatchedBridgeConfig"] = bridgeConfigDictionary;
[[context evaluateScript:bundleScriptString] callWithArguments:@[reactGlobal]];

Accessing the global require function from Obj-C is simple as well:

JSValue *exports = [reactGlobal[@"require"] callWithArguments:@[@"moduleName"]];
[exports invokeMethod:@"doSomething" withArguments:@[...]];

So in the end, RCTJavaScriptExecutor has a smaller API and ReactKit is better encapsulated by reducing pollution of the global scope (some functions like setTimeout need another approach though).

---

For the Chrome debugger extension, it might be possible to keep using the real global object with the help of the packager by serving (function(global) { /* ... */ })(window);.

[sahrens]

Closing for now since it doesn't sound like this is blocking anything.