-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
Comments
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. |
You can use a base64 data URL containing the entire JS file as a string. Is that a viable solution for you? |
@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. |
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. |
The delegate should address this. |
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.
The text was updated successfully, but these errors were encountered: