Fix warning when loading RCTUIManager in the old architecture #42733
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
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D53225120 |
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Jan 30, 2024
Summary:
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
1. We know we are in the main queue
2. We know we are going to need it (so it is not violating the lazy load principle)
3. We know it is safe.
This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module.
## Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Differential Revision: D53225120
cipolleschi
force-pushed
the
export-D53225120
branch
from
7eb100d
to
137628f
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53225120 |
cipolleschi
force-pushed
the
export-D53225120
branch
from
137628f
to
ab64345
Compare
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Jan 31, 2024
Summary:
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
1. We know we are in the main queue
2. We know we are going to need it (so it is not violating the lazy load principle)
3. We know it is safe.
This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module.
## Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Differential Revision: D53225120
|
This pull request was exported from Phabricator. Differential Revision: D53225120 |
cipolleschi
force-pushed
the
export-D53225120
branch
from
ab64345
to
f0a928d
Compare
cipolleschi
added a commit
to cipolleschi/react-native
that referenced
this pull request
Feb 7, 2024
Summary:
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
1. We know we are in the main queue
2. We know we are going to need it (so it is not violating the lazy load principle)
3. We know it is safe.
This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module.
## Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Differential Revision: D53225120
|
This pull request was exported from Phabricator. Differential Revision: D53225120 |
Summary:
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
1. We know we are in the main queue
2. We know we are going to need it (so it is not violating the lazy load principle)
3. We know it is safe.
This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module.
## Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Reviewed By: philIip
Differential Revision: D53225120
cipolleschi
force-pushed
the
export-D53225120
branch
from
f0a928d
to
4665710
Compare
|
This pull request was exported from Phabricator. Differential Revision: D53225120 |
|
This pull request has been merged in dc38988. |
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:
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
This should allow us to also remove the feature flag of
RCTUIManagerDispatchAccessibilityManagerInitOntoMainbecause now it is safe to use the main_queue as requested by the module.Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Differential Revision: D53225120