-
Notifications
You must be signed in to change notification settings - Fork 24.5k
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
introduce CallInvokerHolder stable API #44381
Conversation
Base commit: 05a4232 |
This pull request was exported from Phabricator. Differential Revision: D56866817 |
Summary: Changelog: [Android][Added] I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after facebook#43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API. this will be forward compatible in the old architecture Reviewed By: RSNara Differential Revision: D56866817
This pull request was exported from Phabricator. Differential Revision: D56866817 |
Summary: Changelog: [Android][Added] I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after facebook#43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API. this will be forward compatible in the old architecture Reviewed By: RSNara Differential Revision: D56866817
This pull request was exported from Phabricator. Differential Revision: D56866817 |
Summary: Changelog: [Android][Added] I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after facebook#43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API. this will be forward compatible in the old architecture Reviewed By: RSNara Differential Revision: D56866817
This pull request was exported from Phabricator. Differential Revision: D56866817 |
Summary: Changelog: [Android][Added] I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after facebook#43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API. this will be forward compatible in the old architecture Reviewed By: RSNara Differential Revision: D56866817
This pull request was exported from Phabricator. Differential Revision: D56866817 |
Summary: Changelog: [Android][Added] I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after facebook#43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API. this will be forward compatible in the old architecture Reviewed By: RSNara Differential Revision: D56866817
This pull request was exported from Phabricator. Differential Revision: D56866817 |
This pull request has been merged in 69bb4fc. |
This pull request was successfully merged by @philIip in 69bb4fc. When will my fix make it into a release? | How to file a pick request? |
Summary: Pull Request resolved: facebook#44381 Changelog: [Android][Added] I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after facebook#43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API. this will be forward compatible in the old architecture Reviewed By: RSNara Differential Revision: D56866817 fbshipit-source-id: 4096847c52559d9a49feb072a0385da6b64392d4
Summary: Pull Request resolved: facebook#44381 Changelog: [Android][Added] I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after facebook#43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API. this will be forward compatible in the old architecture Reviewed By: RSNara Differential Revision: D56866817 fbshipit-source-id: 4096847c52559d9a49feb072a0385da6b64392d4
Summary:
Changelog: [Android][Added]
I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after #43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API.
this will be forward compatible in the old architecture
Differential Revision: D56866817