Merge up to 0.75 branch cut #2157
Merged
+148,852
−120,850
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
Summary: Changelog: [Internal] Reviewed By: pieterv Differential Revision: D57939041 fbshipit-source-id: 738523fac25112ab3c75bde0c09b2df62c29aa9c
Summary: Pull Request resolved: facebook#44705 `focusable` props behaviors are inconsistent across different flavors of Touchable components. Some use the disabled prop to check if the component should be focusable, others do not. This ensures all Touchable* component flavors use the disabled prop. ## Changelog [General][Fixed] Fixed inconsistency in TouchableX component disabled / focusable behavior Reviewed By: yungsters Differential Revision: D57910488 fbshipit-source-id: af17227403338fcd5bebd9ba7c3172b4c6776e1f
Summary: Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier. Re-create from facebook#43110 but for iOS ## Changelog: [IOS] [ADDED] - Add BindingsInstaller for TurboModules Pull Request resolved: facebook#44486 Test Plan: Added test in RN-Tester TurboModule test case Reviewed By: javache Differential Revision: D57224891 Pulled By: philIip fbshipit-source-id: fabe5c4f8d2087ac9a465f2cb90d884b83265a68
Summary: isaacs/node-glob#493 Fixes facebook#44712 ## Changelog: [General][Fixed] - Use consistent version of glob in react-native Pull Request resolved: facebook#44713 Reviewed By: yungsters Differential Revision: D57949442 Pulled By: NickGerleman fbshipit-source-id: 9ea246c6b5307370628f34a78373a8bddb42420d
Summary: Pull Request resolved: facebook#44711 This adds just the border clipping examples and tests from D57668976 Changelog: [Internal] Reviewed By: yungsters Differential Revision: D57941945 fbshipit-source-id: 2234927cb944710c9d929d1d77087d3d2ecdbca6
Summary: Pull Request resolved: facebook#44708 Changelog: [internal] We had a fallback to use a Hermes internal API if the native module exposing `queueMicrotask` wasn't available. This is no longer necessary as the module is available everywhere we enable the event loop, so we can remove it. Reviewed By: christophpurrer Differential Revision: D57922076 fbshipit-source-id: 0ca48abacd77a75ce8559db08f55c78a3e0ec815
… tests (facebook#44642) Summary: On React Native macOS (I am not sure with the current state of React Native), the Xcode Unit and Integration tests are a bit flaky. Rather than set "retry on failure up to 3 times" through the pipeline config (in our case, Azure Pipelines), I realized my earlier PR to use Xcode test plans (facebook#36443) means we can have Xcode retry the test. This should be faster than retrying it on the pipeline, because it retries just the failing test, not the entire "test" step. I did this on React Native macOS, so I'm doing it upstream so we can remove a diff. ## Changelog: [INTERNAL] [CHANGED] - Set `retryOnFailure` for Xcode Unit and Integration tests Pull Request resolved: facebook#44642 Test Plan: CI should pass (faster) Reviewed By: cortinico Differential Revision: D57662523 Pulled By: cipolleschi fbshipit-source-id: 8de2ab0ea15ba4d38c3b5bf96108c0c7ff5e9f32
Summary: Pull Request resolved: facebook#44716 Move to listr2 which handle non-TTY environment, outputting to CircleCI logs in a useful way. This gives our CI users more useful debugging information, but limits the output when running locally. If you want more explicit output locally, do something like: ``` yarn run build | cat ``` Changelog: [Internal] Reviewed By: cortinico Differential Revision: D57915369 fbshipit-source-id: ae9f87b0b9608f16ee035b791c5f7b81544c498c
Summary: Pull Request resolved: facebook#44719 Removed shadowing of generic values, which would cause warnings. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D57915364 fbshipit-source-id: 6abf68a62fca88687343ac5677ac905e87220a91
…4727) Summary: Pull Request resolved: facebook#44727 This is a re-land of facebook#44048 Reverting it caused even bigger regression, so my earlier assessment was wrong. The initial regression was caused by something else. Changelog: [Internal] - Let's keep the changelog entry form the original diff. Reviewed By: fkgozali Differential Revision: D57970133 fbshipit-source-id: c683d661a805d44434f5491e89dd4b7218379bee
…ached (facebook#44724) Summary: Pull Request resolved: facebook#44724 Changelog: [internal] Batching operations at this layer was wrong because these are the operations that were already flushed by the mounting layer but were accumulated in `SurfaceMountingManager` because the root view wasn't created. These operations should be executed before anything else that's scheduled in the `MountItemDispatcher`, so we should never batch them. The problem this was trying to solve is solved in a different way in D57968937. This was gated so this shouldn't affect any current usages. Reviewed By: sammy-SC Differential Revision: D57968939 fbshipit-source-id: e9131614cdc76e9d553540757611bc8b0736c927
…adlocks (facebook#44725) Summary: Pull Request resolved: facebook#44725 Changelog: [internal] ## Context We're currently testing synchronous state updates in Fabric (committing shadow trees for state updates synchronously in the thread where they were dispatched, instead of always scheduling it in the JS thread). In these experiments we saw a problem caused by a recent change in the Android mounting layer (done to fix a problem with the Event Loop) where we were doing the mount operations inside a mutex lock. The problem is that we didn't have recursive commit+mount operations (because we were dispatching state updates in the JS thread) but now that we do we get a deadlock here. {F1659804385} These recursive commit+mount operations happen because it's possible to trigger state updates while we mount changes in the host platform (e.g.: we create the scroll view and we update the state to set the content offset). Those state updates trigger more mount operations, which deadlock in the mentioned place. ## Changes This fixes the described issue by restricting the lock only to access the list of pending operations, but not to apply them. In the current implementation, `mountingManager->executeMount` is protected by the lock, whereas in the new version it isn't (so it can be safely called recursively). The synchronization of the mount operations is done directly at the mounting layer on Android. Reviewed By: sammy-SC Differential Revision: D57968936 fbshipit-source-id: 52f996d212cad691646610632b03b5223e7e90ca
…cebook#44726) Summary: Pull Request resolved: facebook#44726 Changelog: [internal] ## Context We ran an experiment to test synchronous state updates in Fabric and we saw some crashes on Android. Those crashes were caused by mounting operations not being applied in the correct order. There were 2 root causes for that problem: 1. State updates triggered during mount would be committed and mounted synchronously during that specific mount operation. That caused problems like trying to clip views that weren't created already (as we were processing the state update for the content offset before we actually created the child views). 2. Same problem as before, but with mount operations that were processed when the root view wasn't available yet (this is a separate queue). We tried to fix the problem in facebook#44015, but the solution for 2) was incorrect, as we didn't account for those operations being in a different queue (it was reverted in facebook#44724). ## Changes I think the right solution for point 2) is that, instead of marking the root view as available and then process all pending operations, we flip those operations. That was, if there are any mount operations as a side-effect of processing that queue, those will also be added to the same queue, instead of being processed immediately in `MountItemDispatcher`. Reviewed By: sammy-SC Differential Revision: D57968937 fbshipit-source-id: 93d10cdeced0c837d4301768aee8575d2c940b10
…acebook#44707) Summary: Pull Request resolved: facebook#44707 Changelog: [Internal] For DrawerLayoutAndroid in New Architecture, when we use ReactDev Tools layout inspection, incorrect node is being shown in the inspector tools. This is because pointerEvents is not set to either `box-none` or `none` based on the drawer open/close state for the drawer child wrapper `View`. Reviewed By: hoxyq Differential Revision: D57873834 fbshipit-source-id: b2b82633969922189a0b96feea2115ddc0b2ebb5
…k#44709) Summary: Pull Request resolved: facebook#44709 Add some extra logging to try to figure out heisenbug, where we cannot find MapBuffer key that we should expect to be present, only during view preallocation. ReadableMapBuffer toString() will itself iterate through MapBuffer entries, so this might not return something sane if underlying MapBuffer is corrupt or wrongly oriented, but should give us more context. We also need to be careful here, to avoid logging the actual state mapbuffer or its binary which may contain text content. Only the paragraph attributes. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D57925730 fbshipit-source-id: cecca1a1fe53b4b417d520e65c30d47243cb2fb2
Summary: Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier. facebook#44486 for Android ## Changelog: [Android] [ADDED] - Add BindingsInstaller for TurboModules Pull Request resolved: facebook#44526 Test Plan: Added test in RN-Tester TurboModule test case {F1660267530} {F1660287029} Reviewed By: javache Differential Revision: D57223328 Pulled By: philIip fbshipit-source-id: d4a69a16f6ce77c0a0fd63f008bea929b1964ab8
Summary: In the previous months, we worked with a GH engineer to run our test workflow on PRs. The workflow was running properly, so we want to run it on main too. ## Changelog: [Internal] - Run gha on main too Pull Request resolved: facebook#44723 Test Plan: GHA is green Reviewed By: cortinico, NickGerleman Differential Revision: D57975230 Pulled By: cipolleschi fbshipit-source-id: 89d06361ad6f2230b7000e05970e9b16539c9164
Summary: Changelog: [General][Fixed] Fixed LogBox not showing correctly on the New Architecture We found an incorrect behavior in the event loop, where an error in a task would prevent its microtasks from running. This isn't spec compliant and should be fixed. This caused LogBox to not work correctly, as error reporting is implemented via microtasks that would never execute. Reviewed By: sammy-SC Differential Revision: D58010521 fbshipit-source-id: 7901c5d6e83fb63af148e12ad6c32be490a3999d
Summary: Pull Request resolved: facebook#44697 Google has discouraged attempting to read the `status_bar_height` resource [since 2017](https://youtu.be/_mGDMVRO3iE?si=qGQd7gLa_qTmfLGL&t=1079). With the introduction of display cutouts there can be a mismatch between the resource value and the true status bar size (and issues like [this one](facebook#33612) popped up). The recommended approach is to instead call `getInsets` with the proper status bar and navigation flags provided by `WindowInsets`. On older APIs where `getInsets` is not supported, we have access to `systemWindowInsetTop`. Changelog: [Android][Fixed] - Fixed StatusBar.currentHeight calculations to honor all cutout sizes Reviewed By: cipolleschi, alanleedev Differential Revision: D57878119 fbshipit-source-id: 9fadd33d5f9b617a70a052c98dbd53fd29281650
Summary: Pull Request resolved: facebook#44744 Correctly handle TurboModule promise rejections when there is no Exception message. Changelog: [Android][Fixed] Android exceptions without a message would lead to unexpected crashes Reviewed By: fabriziocucci Differential Revision: D58014797 fbshipit-source-id: c94042818a00669a1be2db8e89e84c6b616efbec
…ebook#44738) Summary: Pull Request resolved: facebook#44738 Changelog: [Internal] Reviewed By: yungsters Differential Revision: D58004147 fbshipit-source-id: f42c939d92a876b8746703c134b246567846c3ee
Summary: Pull Request resolved: facebook#44728 This makes them identical so the diff that makes them diverge is clear. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D57970711 fbshipit-source-id: 8586ef202ad27796918378832fa62df1708a0218
Summary: Pull Request resolved: facebook#44668 Enables regenerator for `hermes-canary`. Along with the previous diff, regenerator is the only difference between `hermes-stable` and `hermes-canary`. Reviewed By: motiz88 Differential Revision: D57742907 fbshipit-source-id: ca14cb50fe976744c7fa2c0b3397e81661359f15
…44732) Summary: Pull Request resolved: facebook#44732 `getBorderBoxPath()` and `getPaddingBoxPath()` currently assume `updatePath()` will set a path, but this does not happen on Android 24 emulators where it seems like `onBoundsChanged` isn't called to set flag for needing update. But, the current design tries to be lazy with path generation, and these are probably more expensive to clip, so we should really make these functions return nullable value, then fall back to rect, like the internals of `CSSBackgroundDrawable`, and how I misremembered these as working in the view code added originally in D57668976. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D57951852 fbshipit-source-id: 33bc8f738950597822ae9026408ab3a23b0923f3
Summary: Pull Request resolved: facebook#44733 We are returning a Path to callers, which shouldn't be mutated. This isn't really safe. Return a copy to external callers instead, if they need a path to work with. Changelog: [Internal] Reviewed By: rshest Differential Revision: D57996157 fbshipit-source-id: 53cd95df6e2641d946f7c3fef40f6449b16ca5cb
Summary: Pull Request resolved: facebook#44735 Add some more examples of overflow clipping for scrollview, text, textinput. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D57999676 fbshipit-source-id: dfede321b2c7c61dda3afaf2aea784f6c295c384
Summary: Pull Request resolved: facebook#44747 changelog: [internal] Change names of systrace blocks to better reflect where the operation is happening. Reviewed By: rubennorte Differential Revision: D57969459 fbshipit-source-id: 3c857a66f060992e1792e18973caafea7c995c5b
Summary: Based on facebook#44723. This PR removes some Old Arch build only jobs on iOS. Some of the recent changes where unifying the build process across archs, so we don't have to build Old and New Arch ## Changelog: [Internal] - Remove OldArch jobs when they are not required Pull Request resolved: facebook#44729 Test Plan: CCI is green Reviewed By: cortinico Differential Revision: D57975238 Pulled By: cipolleschi fbshipit-source-id: ffd0ff0534f25019d501aa3862baee1442088784
Summary: Pull Request resolved: facebook#44480 TextInputs' onTextInput callback was removed way back in React Native 0.62 with facebook@3f7e0a2 , but remnants of the implementation exists. Fully remove references on JS side now that no older clients are emitting this event Changelog: [General][Removed] Remove viewconfigs for onTextInput callbacks Reviewed By: cipolleschi Differential Revision: D57092733 fbshipit-source-id: 62dae37d8e8f155969a1ca65131d4ee9a1d5f1c4
Summary: Pull Request resolved: facebook#44720 Bug fixes to bootstrap, build and bundle on iOS. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D57915363 fbshipit-source-id: 1c82f0020572d7d9bf599a7c568dfc6f3a3292e8
Summary: Migrate TouchableWithoutFeedback-test to `act`-wrapping abstraction for `react-test-renderer` `create` in preparation for React 19. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D58653765 fbshipit-source-id: 901ea10ec5dd72f8403a84cfd9f9e8ed55dbe04c
Summary: Migrate FlatList-test to `act`-wrapping abstraction for `react-test-renderer` `create` in preparation for React 19. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D58653845 fbshipit-source-id: 426fcef454927cee0eb2c38ef16c82106354e5d9
…eate Summary: Migrate assetRelativePathInSnapshot-test to `act`-wrapping abstraction for `react-test-renderer` `create` in preparation for React 19. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D58653908 fbshipit-source-id: 432b172348c445b1684e60cf60b6ab94d62f21e1
…acebook#44997) Summary: Pull Request resolved: facebook#44997 Wrap `VirtualizedList-test` uses of `react-test-renderer` in `act` as appropriate, so as to pass under current React and mostly pass under React 19, with further fixes to come. Changelog: [Internal] Reviewed By: robhogan Differential Revision: D58649295 fbshipit-source-id: 5e0fa791d581fbf004a2ca7eaa5c4b4d9a15ddfe
Summary: Pull Request resolved: facebook#45002 There are a couple Jest unit test cases for `VirtualizedList-test.js` that require further investigation. We believe that these are problems with Jest fake timers in the test and not with the component itself, so for now let's skip them so as to unblock the upgrade to React 19. Changelog: [Internal] Reviewed By: robhogan Differential Revision: D58656948 fbshipit-source-id: d52f3ad8277def6eae20cbbc11751d73b769d929
Summary: Pull Request resolved: facebook#44989 Enables these 2 global feature flags for React Native Jest testing: - `IS_REACT_ACT_ENVIRONMENT` - `IS_REACT_NATIVE_TEST_ENVIRONMENT` Changelog: [General][Changed] - Enables React global flag that causes Jest testing environment to require `act()` Reviewed By: robhogan Differential Revision: D58644562 fbshipit-source-id: 4de5ea3a89e8ca99ac4c1c21721872db4f5552b3
Summary: Pull Request resolved: facebook#44990 Upgrades React Native and Relay to depend on React 19, which is currently published as release candidates. This is in preparation for React Native 0.75. This will depend on updating open source renderers after [facebook/react#29903](facebook/react#29903) is merged. Changelog: [General][Changed] - Upgrade to React 19 Reviewed By: robhogan Differential Revision: D58625271 fbshipit-source-id: f9ad95b18716a9ce02f7cfbcc7248bdfb244c010
Summary: Pull Request resolved: facebook#44991 Updates the open source renderers for React 19. This is in preparation for React Native 0.75. Notable, this incorporates the feature flag changes from [facebook/react#29903](facebook/react#29903). Changelog: [General][Changed] - Upgrade Renderers for React 19 Reviewed By: robhogan Differential Revision: D58632199 fbshipit-source-id: 674bb47554e4b0c6ab5127fb9683ed8284b7a4ce
Summary: Closes facebook#43648. `accessibilityLabel` is overridden on `RCTParagraphComponentView`: https://github.com/facebook/react-native/blob/fe06cbfbf332a999e065bdc13ef5cdeed20c5517/packages/react-native/React/Fabric/Mounting/ComponentViews/Text/RCTParagraphComponentView.mm#L157-L160 Effectively making it ignore whatever is set in the prop on the component. This PR updates the overridden method to check if the prop is set (and return that if it is) before returning the text as a label. ## Changelog: [IOS] [FIXED] - Fix the accessibility label not being applied to text components on the new architecture Pull Request resolved: facebook#45003 Test Plan: Tried out on the reproduced from the issue. |Text with label set|Text with no label set| |-|-| |<img width="982" alt="Screenshot 2024-06-17 at 08 33 58" src="https://github.com/facebook/react-native/assets/21055725/646014b3-5e9e-4023-8fe7-6dd65f04b217">|<img width="982" alt="Screenshot 2024-06-17 at 08 34 12" src="https://github.com/facebook/react-native/assets/21055725/2d712ced-ab78-4f8d-b482-b30df53ca949">| Reviewed By: javache Differential Revision: D58664380 Pulled By: cipolleschi fbshipit-source-id: 88b45ca859283e16472630675b66a12732be6388
Summary: Implements `requestIdleCallback` and `cancelIdleCallback` ### Notes Proposed implementation does yet cover all WHATWG eventloop requirements. - Deadline computation is not implemented and is polyfilled by giving each callback `50ms`, rather than it being shared between other idle callbacks. - The requested callbacks are called with lowest priority by the scheduler as of now, but the execution is not as described in the standard. ## Changelog: - [GENERAL] [ADDED] - Implemented `requestIdleCallback` and `cancelIdleCallback` Pull Request resolved: facebook#44759 Reviewed By: javache, sammy-SC Differential Revision: D58415077 Pulled By: rubennorte fbshipit-source-id: 46189d4e3ca1d353fa6059a904d677c28c61b604
Summary: Pull Request resolved: facebook#45005 We've had failures owing to running out of disk space, however this isn't a stable failure. Adding more data about disk availability and utilisation to help debug these issues. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D58667190 fbshipit-source-id: 3d5f7cc985ac71044818f7b5663ef7400ad691b5
…book#44957) Summary: After updating my project to 0.73.2 I noticed that even though I had a specific port set in my `metro.config.js`, every time I'd start my project, it was running on port 8081. Passing the `--port` argument would allow me to change the port, but the config from metro did not. I checked if the metro config was being properly applied, using `--verbose` and it was. So I dug a bit, trying to figure out what had changed and noticed the coalescing of the value, whenever the argument `--port` is not present. That seemed odd since it meant that there's always a port defined for the `options` of `loadMetroConfig`, which would always be used in the `loadConfig` step. To confirm I was on the right track I went to the [cli-plugin-metro](https://github.com/react-native-community/cli/blob/v11.3.10/packages/cli-plugin-metro) repo, to the last release before the move here, and noticed that there was [no coalescing in the same method](https://github.com/react-native-community/cli/blob/v11.3.10/packages/cli-plugin-metro/src/commands/start/runServer.ts#L60). In this PR, I remove the coalescing of the port from `runServer.js` from the `community-cli-plugin`, to allow the port configuration through `metro.config.js`. ## Changelog: [INTERNAL] [FIXED] - Fix server port configuration via `metro.config.js` <!-- Help reviewers and the release process by writing your own changelog entry. Pick one each for the category and type tags: For more details, see: https://reactnative.dev/contributing/changelogs-in-pull-requests Pull Request resolved: facebook#44957 Test Plan: Running `yarn start` and verifying that: - it would listen to port `8081` if no argument nor a custom port was set in `metro.config.js` - it would listen to port `8082` if that one was defined in `metro.config.js` - it would listend to port `8083` if that port was passed as an argument to the command (i.e. `yarn start --port 8083` even though port 8082 was defined in `metro.config.js` Reviewed By: cortinico Differential Revision: D58605152 Pulled By: robhogan fbshipit-source-id: 9cf7a8b6a0d9de3af1ca4092906b4c648acee373
Summary: Pull Request resolved: facebook#45006 The steps were pointing to an incorrect folder. Updated to points to react-native/packages Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D58669426 fbshipit-source-id: b58b9bc7d8c7860f2f46c8bdf4bf0636e82ee357
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
packages/debugger-frontend/dist/third-party/front_end/core/platform/platform.js
Dismissed
Show dismissed
Hide dismissed
packages/debugger-frontend/dist/third-party/front_end/core/platform/platform.js
Dismissed
Show dismissed
Hide dismissed
packages/debugger-frontend/dist/third-party/front_end/core/platform/platform.js
Dismissed
Show dismissed
Hide dismissed
packages/debugger-frontend/dist/third-party/front_end/core/platform/platform.js
Dismissed
Show dismissed
Hide dismissed
...s/debugger-frontend/dist/third-party/front_end/legacy_test_runner/test_runner/test_runner.js
Dismissed
Show dismissed
Hide dismissed
Saadnajmi
force-pushed
the
75-merge
branch
6 times, most recently
from
64b395e to
c27953a
Compare
JunielKatarn
approved these changes
Aug 21, 2024
Saadnajmi
force-pushed
the
75-merge
branch
3 times, most recently
from
17c70b6 to
f680a00
Compare
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.
Merge up to facebook@6f7eae5 , the commit for the
0.75-stablebranch cut.Summary:
Interesting upstream changes:
packages/react-native/local-cli, as React Native is reducing its dependency on@react-native-community/cli.run-macoscommand.focusableconsistent withdisabled. I also modified our macOS propacceptsFirstMouseto match.TouchableWithoutFeedbackwas rewritten as a Function component using Pressability. We needed to update our implementation to match.HostPlatformColor.mmwhere we have to handle an assert.setIsSecondaryClickToShowDevMenuEnabledRCTUIViewtoRCTPlatformViewinside RCTScrollView.RCTSendScrollEventForNativeAnimations_DEPRECATEDis now implemented for macOSself.contentViewinstead of_contentView. I undid these. We should make sure these are proper, and if so, upstream the change.@availabilitycheck for macOS 11…### Other interesting changes:
InputAccessoryViewto only iOS. This isn’t relevant for macOS or visionOS.RCTImageLoaderintroduced way back with 4b19d14 . They don’t seem to be necessary anymoreRCTPausedInDebuggerOverlayController. This is used by the experimental new debugger with Hermes.Other notes There’s an increasing amount of places where upstream code calls
UIView.backgroundColor = <>. This is one of those things that doesn’t entirely work properly withoutRCTUIView, but in most places, I useRCTPlatformView(akaNSView) and shim it as follows: ``` #if !TARGET_OS_OSX // [macOS]view.backgroundColor = [UIColor systemBackgroundColor];
#else // [macOS
view.wantsLayer = true;
view.layer.backgroundColor = [[NSColor windowBackgroundColor] CGColor];
#endif // macOS]
``` This mostly works.. except for Light/Dark mode, because the background color won’t update. To properly implement
backgroundColor, we need to override `displayLayer`. `RCTUIView` already does this, so perhaps the followup is to update most uses to use RCTUIView. Also, maybe `RCTUIKit` should be a separate pod altogether?Test Plan:
Ci should pass.
List of merge conflicts