Pass jsi::Runtime reference into CallInvoker::invoke* callbacks #43375
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D54643171 |
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…book#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
|
This pull request was exported from Phabricator. Differential Revision: D54643171 |
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…acks (facebook#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
|
This pull request was exported from Phabricator. Differential Revision: D54643171 |
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…book#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
|
This pull request was exported from Phabricator. Differential Revision: D54643171 |
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…acks (facebook#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…book#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…book#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
|
This pull request was exported from Phabricator. Differential Revision: D54643171 |
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…book#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
|
This pull request was exported from Phabricator. Differential Revision: D54643171 |
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…book#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
|
This pull request was exported from Phabricator. Differential Revision: D54643171 |
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…book#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 7, 2024
…book#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
|
This pull request was exported from Phabricator. Differential Revision: D54643171 |
rshest
added a commit
to rshest/react-native
that referenced
this pull request
Mar 8, 2024
…acks (facebook#43375) Summary: ## Changelog: [Internal] - As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user. There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread. So far people have been coming up with all kinds of workarounds for that, none of them safe enough. Reviewed By: rubennorte Differential Revision: D54643171
|
This pull request has been merged in 76ce789. |
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 2, 2024
Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 2, 2024
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 Differential Revision: D56866817
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
…44378) Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
…44378) Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
…44378) Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
…44378) Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
…44378) Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
…44378) Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
…44378) Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 3, 2024
Summary: Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994
facebook-github-bot
pushed a commit
that referenced
this pull request
May 3, 2024
Summary: Pull Request resolved: #44378 Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994 fbshipit-source-id: 5c3585356d016a50645eda3af2d3bbe00298b4e4
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 4, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 4, 2024
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
philIip
added a commit
to philIip/react-native
that referenced
this pull request
May 4, 2024
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
facebook-github-bot
pushed a commit
that referenced
this pull request
May 4, 2024
Summary: Pull Request resolved: #44381 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 Reviewed By: RSNara Differential Revision: D56866817 fbshipit-source-id: 4096847c52559d9a49feb072a0385da6b64392d4
kosmydel
pushed a commit
to kosmydel/react-native
that referenced
this pull request
May 6, 2024
Summary: Pull Request resolved: facebook#44378 Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994 fbshipit-source-id: 5c3585356d016a50645eda3af2d3bbe00298b4e4
kosmydel
pushed a commit
to kosmydel/react-native
that referenced
this pull request
May 6, 2024
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
kosmydel
pushed a commit
to kosmydel/react-native
that referenced
this pull request
Jun 11, 2024
Summary: Pull Request resolved: facebook#44378 Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules 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. Reviewed By: RSNara Differential Revision: D56807994 fbshipit-source-id: 5c3585356d016a50645eda3af2d3bbe00298b4e4
kosmydel
pushed a commit
to kosmydel/react-native
that referenced
this pull request
Jun 11, 2024
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
This was referenced Aug 18, 2024
|
@rshest I see that care was made in this PR to provide signatures for backward compatibility, but these were only added for overload that doesn't take a SchedulerPriority as first argument. We depend on the overload that does take a This caused realm-js#6845 and realm-js#6846. I wanted to flag this here first, in case you want to do a quick follow-up PR. I can also create an issue to track this separately. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Changelog:
[Internal] -
As discussed with the team, it makes more sense to pass the reference to the correct
jsi::Runtimeobject as an argument to theCallInvoker::invoke*callbacks, that are provided by the user.There are various use cases when user would like to get a hold of the
jsi::Runtimein the callback, and it makes sense, since it is guaranteed to run on the JS thread.So far people have been coming up with all kinds of workarounds for that, none of them safe enough.
Differential Revision: D54643171