-
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
Timing of native view commands is incorrect on iOS in the new architecture #47576
Comments
Warning Could not parse version: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2. |
Warning Missing reproducer: We could not detect a reproducible example in your issue report. Please provide either:
|
Warning Could not parse version: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2. |
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 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
…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
…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
…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
Description
In the new architecture, native view commands are dispatched immediately to the UI thread:
react-native/packages/react-native/React/Fabric/Mounting/RCTMountingManager.mm
Lines 206 to 219 in f3b7c7c
But mounting operations are only flushed at the end of the current task in the event loop / runtime scheduler.
That causes problems when invoking native view commands on views that were just created, e.g.:
In this case, the steps RN follows are:
4.1 UI: Execute native view command
4.1 JS: finish task and dispatch mount operations to UI thread.
On Android, this works correctly because we queue the native view command in the same queue as mount operations, so they're always processed in the right order. We need to do something similar on iOS to fix this issue.
React Native Version
0.76
Affected Platforms
Runtime - iOS
Areas
Fabric - The New Renderer
The text was updated successfully, but these errors were encountered: