[Loader] define RCTBridgeDelegate and delegate JS loading to it

[ide]

hey @tadeuzagallo - I would like to be able to control the JS loading process myself so that I can handle errors differently and implement other custom behavior. Do you have plans to do this or would you accept a PR that makes this change? The idea I have is to add a delegate to the bridge called RCTBridgeDelegate. It would look like this:

@protocol RCTBridgeDelegate
@optional
- (void)loadJavaScriptAtURL:(NSURL *)URL
                 onComplete:(void (^)(NSError *error, NSString *script))block;
@end

The default implementation of this delegate method would use the existing RCTJavaScriptLoader and it is backwards-compatible with existing code.

[jwyld]

I'm wanting better control over this as well. This was my hope with #1463.

I was investigating the route more like the executorClass is done.

[jwyld]

Depending on the intent of use for the loader, another issue which is related is #1652.

[ide]

Re: use cases -- another thing I wanted to do was add a progress bar to get a better visual sense of whether loading the script is slow or if the bottleneck is elsewhere.

[jwyld]

I've filed a few issues around the loading and the bridge setup. In my case, the code is coming off disk. I changed the loader to page is directly, and my code is in UTF16 format. There is no UTF8 conversion cost, no overhead allocation cost, and it helps the lex a little bit as well. I've moved the loader creation to be earlier, so I can start the paging right away and allow the bridge to get set up in the meantime. There is a semaphore wait in the bridge which causes a stall. Moving some things around and allowing the bridge to do some things in parallel has dropped the stall.

My point is if you aren't downloading off the network, the bridge is adding overhead. The majority of the time is the JS lex.

I'm processing through more performance runs to see what can be done.

[brentvatne]

👍 this is a nice idea

[ide]

Thanks @tadeuzagallo =)