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

JSExport'd objects (or alternative) aren't supported #15367

Closed
mhuusko5 opened this issue Aug 4, 2017 · 2 comments
Closed

JSExport'd objects (or alternative) aren't supported #15367

mhuusko5 opened this issue Aug 4, 2017 · 2 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@mhuusko5
Copy link

mhuusko5 commented Aug 4, 2017

Currently the native bridge is 1) very simple (lump modules) 2) boilerplate heavy (macros/wrappers for desired exports, objects/data needing JSONification) 3) limited to Obj-C (or Swift wrapped/de-typed in Obj-C)

#1 and #2 could be solved by supporting the native JavaScriptCore JSExport protocol functionality, so that arbitrary Obj-C objects are passable to/interactable from JS land. If this is possible as a short term measure, it would be very valuable.

But I imagine a fine grained, full, automatic bridge unique to RN could be (and would need to be, to provide the same functionality for Android) developed in the longer term, given the skill/knowledge base that participates in this project.
I'm imagining, for example, a native bridge between JS<->Obj-C, TS<->Swift that's code-gen'd for full support of each's interfaces/lang features. Has something like this ever been played with?

@ide
Copy link
Contributor

ide commented Aug 4, 2017

If you are looking to invoke native code synchronously from JS, the CxxBridge modules support this.

JSExport wouldn't work on Android and it doesn't go through the JS bridge so it's a bit of a non-starter but for your own projects you can get the JSCExecutor from the CxxBridge (need a private category) and the JSContext from that. If you call RN functions from code invoked by JSContext, they might get scheduled outside the RN event loop and cause bugs, so be very careful.

It doesn't make sense for RN to support this nor encourage it, the pitfalls are non-obvious.

@pull-bot
Copy link

pull-bot commented Oct 9, 2017

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

  • Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
  • If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
  • Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

@hramos hramos added the Icebox label Oct 9, 2017
@hramos hramos closed this as completed Oct 9, 2017
@facebook facebook locked as resolved and limited conversation to collaborators Oct 9, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Oct 9, 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