This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse the repository at this point in the history
Remove main queue execution of constantsToExport
Summary: ## Context - If a NativeModule requires main queue setup, its `constantsToExport` method is executed on the main queue. - In the TurboModule system, `constantsToExport` or `getConstants` is treated like a regular synchronous NativeModule method. Therefore, it's always executed on the JS thread. This difference in behaviour is dangerous when we're A/B testing the TurboModule infra: One could write a NativeModule that requires main queue setup, and have it expose constants that access objects/state only accessible on the UI thread. This NativeModule would work fine in the legacy infra, which could be the case if the NativeModule author is testing locally. But once it ships to prod, it may run with the TurboModule system, and crash the application. To mitigate this risk, I'm removing this special main queue execution of `constantsToExport` from the legacy infrastructure. ## Consequences - If a NativeModule's `constantsToExport` method accesses objects/state only accessible on the UI thread, it must do so by explicitly scheduling work on the main thread. I wrote up a codemod to fix this for our OSS modules: D21797048. - Eagerly initialized NativeModules that required main queue setup had their constants calculated eagerly. After the changes in this diff, those NativeModules will have their constants calculated lazily. I don't think this is a big deal because only a handful of NativeModules are eagerly initialized, and eagerly initialized NativeModules are going away anyway. Changelog: [iOS][Removed] - Main queue execution of constantsToExport in NativeModules requiring main queue setup Reviewed By: fkgozali Differential Revision: D21829091 fbshipit-source-id: df21fd5fd2ef45a291c07400f360bba801ae290f
- Loading branch information
Showing 3 changed files with 21 additions and 2 deletions.