Skip to content
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

[Bridge] RCTRootView and RCTBridge can only be created with URL #1463

Closed
jwyld opened this issue May 30, 2015 · 5 comments
Closed

[Bridge] RCTRootView and RCTBridge can only be created with URL #1463

jwyld opened this issue May 30, 2015 · 5 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@jwyld
Copy link
Contributor

jwyld commented May 30, 2015

Going through the work of providing a URL to the source is actually slower (noticeably so) for a situation when I have the JS string already.

Speed of startup is very important for me. I have the JS code mapped from disk and in Unicode format already. If I could hand the string I have to the root view creation or to a bridge and then into a root view, this would be a huge win for me. This would bypass the NSURLSessionDataTask as well as the cost of the NSString allocation for the raw text in the JS loader. Additionally, it speeds up the cost of lex in JavaScriptCore by a fraction because the calls through NSString are faster when dealing with native Unicode.

@brentvatne brentvatne changed the title RCTRootView and RCTBridge can only be created with URL [Bridge] RCTRootView and RCTBridge can only be created with URL May 30, 2015
@ide
Copy link
Contributor

ide commented May 30, 2015

To generalize would it make sense to expose the JS loader and allow custom implementations to be injected? One thing I've wanted to do with the loader is also have a better notion of progress, so custom loaders would let me achieve that and address this issue at the same time.

@nicklockwood
Copy link
Contributor

You can use a base64 data URL containing the entire JS file as a string. Is that a viable solution for you?

@jwyld
Copy link
Contributor Author

jwyld commented Jun 1, 2015

@nicklockwood "Speed of startup is very important for me." base64 is going to add way too much overhead. In my case, I have a mapped Unicode string. By using such, I pay no cost for CFString to convert from UTF8. Since it's a "native" string, it removes much of the string overhead cost for lex as well.

@nicklockwood
Copy link
Contributor

Fair enough. It should be fairly simple to add an alternative constructor to RCTBridge that accepts a script string. If you want to make a PR for it, I'm happy to review.

@ide
Copy link
Contributor

ide commented Aug 15, 2015

The delegate should address this.

@ide ide closed this as completed Aug 15, 2015
@facebook facebook locked as resolved and limited conversation to collaborators Jul 22, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

5 participants