synchronise dispatching of view commands through RuntimeScheduler #47604
+169
−51
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: D65909191 |
sammy-SC
force-pushed
the
export-D65909191
branch
from
11c1a1e
to
133896a
Compare
sammy-SC
added a commit
to sammy-SC/react-native
that referenced
this pull request
Nov 14, 2024
…cebook#47604) Summary: ## Changelog: [iOS] [Fixed] - Fixed use of view commands from layout effects Mounting of views is delayed by runtime scheduler to allow React to run layout effects. Execution of view commands must by queued together with mounting of views, otherwise it might be executed before views are mounted. When this happens, view commands are ignored. So before, if view command was executed from layout effect (or ref function), it would get dispatched to the UI thread as quickly as possible. But mounting of views would be delayed. To fix this, both mounting of views and view commands are put on the same queue inside of RuntimeScheduler. ## What about Android? Android employs a [retry mechanism](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.java#L211) that was needed for react tag based view commands. In paper, one could send a view command to a react tag which was completely disconnected from whether a view exists or not. iOS was built with ref commands in mind, so it doesn't have this mechanism. Fixes: facebook#47576 Reviewed By: javache, cipolleschi Differential Revision: D65909191
|
This pull request was exported from Phabricator. Differential Revision: D65909191 |
8 tasks
sammy-SC
added a commit
to sammy-SC/react-native
that referenced
this pull request
Nov 15, 2024
…cebook#47604) Summary: ## Changelog: [iOS] [Fixed] - Fixed use of view commands from layout effects Mounting of views is delayed by runtime scheduler to allow React to run layout effects. Execution of view commands must by queued together with mounting of views, otherwise it might be executed before views are mounted. When this happens, view commands are ignored. So before, if view command was executed from layout effect (or ref function), it would get dispatched to the UI thread as quickly as possible. But mounting of views would be delayed. To fix this, both mounting of views and view commands are put on the same queue inside of RuntimeScheduler. ## What about Android? Android employs a [retry mechanism](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.java#L211) that was needed for react tag based view commands. In paper, one could send a view command to a react tag which was completely disconnected from whether a view exists or not. iOS was built with ref commands in mind, so it doesn't have this mechanism. Fixes: facebook#47576 Reviewed By: javache, cipolleschi Differential Revision: D65909191
sammy-SC
force-pushed
the
export-D65909191
branch
from
133896a
to
8bcd1c8
Compare
|
This pull request was exported from Phabricator. Differential Revision: D65909191 |
sammy-SC
force-pushed
the
export-D65909191
branch
from
8bcd1c8
to
83d1647
Compare
sammy-SC
added a commit
to sammy-SC/react-native
that referenced
this pull request
Nov 15, 2024
…cebook#47604) Summary: ## Changelog: [iOS] [Fixed] - Fixed use of view commands from layout effects Mounting of views is delayed by runtime scheduler to allow React to run layout effects. Execution of view commands must by queued together with mounting of views, otherwise it might be executed before views are mounted. When this happens, view commands are ignored. So before, if view command was executed from layout effect (or ref function), it would get dispatched to the UI thread as quickly as possible. But mounting of views would be delayed. To fix this, both mounting of views and view commands are put on the same queue inside of RuntimeScheduler. ## What about Android? Android employs a [retry mechanism](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.java#L211) that was needed for react tag based view commands. In paper, one could send a view command to a react tag which was completely disconnected from whether a view exists or not. iOS was built with ref commands in mind, so it doesn't have this mechanism. Fixes: facebook#47576 Reviewed By: javache, cipolleschi Differential Revision: D65909191
|
This pull request was exported from Phabricator. Differential Revision: D65909191 |
…cebook#47604) Summary: ## Changelog: [iOS] [Fixed] - Fixed use of view commands from layout effects Mounting of views is delayed by runtime scheduler to allow React to run layout effects. Execution of view commands must by queued together with mounting of views, otherwise it might be executed before views are mounted. When this happens, view commands are ignored. So before, if view command was executed from layout effect (or ref function), it would get dispatched to the UI thread as quickly as possible. But mounting of views would be delayed. To fix this, both mounting of views and view commands are put on the same queue inside of RuntimeScheduler. ## What about Android? Android employs a [retry mechanism](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.java#L211) that was needed for react tag based view commands. In paper, one could send a view command to a react tag which was completely disconnected from whether a view exists or not. iOS was built with ref commands in mind, so it doesn't have this mechanism. Fixes: facebook#47576 Reviewed By: javache, cipolleschi Differential Revision: D65909191
sammy-SC
force-pushed
the
export-D65909191
branch
from
83d1647
to
13981e4
Compare
|
This pull request was exported from Phabricator. Differential Revision: D65909191 |
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:
[iOS] [Fixed] - Fixed use of view commands from layout effects
Mounting of views is delayed by runtime scheduler to allow React to run layout effects. Execution of view commands must by queued together with mounting of views, otherwise it might be executed before views are mounted. When this happens, view commands are ignored.
So before, if view command was executed from layout effect (or ref function), it would get dispatched to the UI thread as quickly as possible. But mounting of views would be delayed. To fix this, both mounting of views and view commands are put on the same queue inside of RuntimeScheduler.
What about Android?
Android employs a retry mechanism that was needed for react tag based view commands. In paper, one could send a view command to a react tag which was completely disconnected from whether a view exists or not.
iOS was built with ref commands in mind, so it doesn't have this mechanism.
Fixes: #47576
Differential Revision: D65909191