forked from facebook/react-native
-
Notifications
You must be signed in to change notification settings - Fork 143
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
chore: Merge up to 0.77.0 #2369
Merged
Merged
+104,117
−70,363
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
…k#47473) Summary: Pull Request resolved: facebook#47473 For example, ``` declare function C<T>(ref: React.RefSetter<Set<T>>): React.Node; type T = React.ElementRef<typeof C> ``` Previously Flow will evaluate `T` to `Set<mixed>`, by automatically replacing generic types with their upper bounds. But in the future it might be replaced with `empty`. This diff cleans up instances like this in react-native codebase. Changelog: [Internal] Reviewed By: alexmckenley Differential Revision: D65562571 fbshipit-source-id: bca2f4f022a5a23a5aa40886f5661899cb315f2e
…r` internal (facebook#47376) Summary: Pull Request resolved: facebook#47376 This makes several classes inside `com.facebook.react.views.progressbar` internal: - ReactProgressBarViewManager - ProgressBarShadowNode - ProgressBarContainerView Those classes should have not been exposed in the first place and users should not depend on them directly. Marked as Breaking but verified that there are no meaningful usages in OSS. Changelog: [Android] [Breaking] - Stable API - Make classes inside `com.facebook.react.views.progressbar` internal Reviewed By: javache Differential Revision: D65423290 fbshipit-source-id: dc98fdca996eb648593adb2c32787cbf0d878e3e
…stContextProvider outside of VirtualizedList (facebook#47463) Summary: Pull Request resolved: facebook#47463 Note this is just a temporary approach which will be cleaned up later. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D65514902 fbshipit-source-id: f722031c5cd34eb1400b3f732fd94c0b03d5434d
…cebook#47254) Summary: The future of Android is [edge-to-edge](react-native-community/discussions-and-proposals#827) and to make the React Native developer experience seamless in this regard, the ecosystem needs to transition from “opaque system bars by default” to “edge-to-edge by default.” Currently, there's no easy way to have edge-to-edge modals, as they are implemented using `Dialog` instances (a separate `Window`) and only provide a `statusBarTranslucent` prop. I tried to implement it in [`react-native-edge-to-edge`](https://github.com/zoontek/react-native-edge-to-edge) by listening to the `topShow` `UIManager` event. But if it works well when there's a defined animation, we can see a quick jump when there's none, because there's too much delay before the event, and edge-to-edge cannot be applied quick enough to the dialog window. ### react-native-edge-to-edge implem with animation (no jump) https://github.com/user-attachments/assets/4933a102-87a5-40e4-98d9-47f8c0817592 ### react-native-edge-to-edge implem without animation (jump) https://github.com/user-attachments/assets/e4675589-08fe-44fe-b9d8-0a6b3552b461 --- For this reason, and because listening to event feels a bit hacky, I think it will be better to go for a new prop directly on RN Modal component: `navigationBarTranslucent` > [!NOTE] > `navigationBarTranslucent` cannot be used without `statusBarTranslucent`, as setting both enable edge-to-edge, like [AndroidX would do](https://github.com/androidx/androidx/blob/androidx-main/activity/activity/src/main/java/androidx/activity/EdgeToEdge.kt) and it would requires extra (and unecessary, given the direction Android is taking) work to find a way to keep the status bar opaque but the navigation bar transparent that work on Android 6 to 15+ ### Additional infos - Colors used for the buttons navigation bar in the PR are the default Android ones ([light](https://github.com/androidx/androidx/blob/androidx-main/activity/activity/src/main/java/androidx/activity/EdgeToEdge.kt#L37) and [dark](https://github.com/androidx/androidx/blob/androidx-main/activity/activity/src/main/java/androidx/activity/EdgeToEdge.kt#L42)) - Compared to the Google implementation, the light scrim is applied from `O_MR1` to `Q` (and not `O` to `Q`) as the [`android:windowLightNavigationBar`](https://developer.android.com/reference/android/R.attr#windowLightNavigationBar) style attribute is not available on `O` (it can only be applied programmatically on API 26). ## Changelog: [ANDROID] [ADDED] - Add navigationBarTranslucent prop to Modal component Pull Request resolved: facebook#47254 Test Plan: Run the tester app, toggle `navigationBarTranslucent`: https://github.com/user-attachments/assets/286d173b-35a5-4951-9105-f9f7562d6764 ----- did some additional testing with RNTester using different justification |flex-start|flex-end| |https://pxl.cl/5Rd20|https://pxl.cl/5Rd21| Reviewed By: javache Differential Revision: D65103501 Pulled By: alanleedev fbshipit-source-id: ef6473ecd785976d3e26c77bbc212222ec96c9f2
Summary: Pull Request resolved: facebook#47354 `PointerValue::invalidate()` is called from `Pointer` destructor, which is implicitly `noexcept`, and from `Pointer` move-assignment operator, which is now `noexcept`. Reviewed By: neildhar Differential Revision: D65271399 fbshipit-source-id: 26fd9707e4389da78537d0d607adaef0c68690ca
Summary: Pull Request resolved: facebook#47399 Deletes `unstable_setEnableSyncOnScroll` which we are no longer experirmenting with in React Native. Changelog: [Internal] - Deleted `unstable_setEnableSyncOnScroll` on `ScrollView`, which was never part of the React Native Public API. Reviewed By: tdn120, sammy-SC Differential Revision: D65449039 fbshipit-source-id: 6608d5ccca477f1da5e0168c4a342cce17014b08
Summary: Pull Request resolved: facebook#47430 Make IntentModule Nullsafe. Fixed nullability warnings. Changelog: [Internal] Reviewed By: tdn120 Differential Revision: D65463226 fbshipit-source-id: 2da597e66ad170ec4a2a2949348e522bb361c209
Summary: This PR fixes a typo in spm.rb ## Changelog: [IOS] [FIXED] - Typo in spm.rb Pull Request resolved: facebook#47480 Test Plan: N/a Reviewed By: GijsWeterings Differential Revision: D65596339 Pulled By: cortinico fbshipit-source-id: c318cec1422dbcb322e70dc5f189d86af42b626d
Summary: Pull Request resolved: facebook#47458 We are in a weird situation where React Native depends on some files that are generated by Codegen. Codegen runs in the user project, so those dependencies are not available to React Native if we try to build it in isolation. This is a problem and a blocker to prepare the prebuilds for iOS. This image show the changes we are introducing: On the right we have the current situation. On the left the new one. {F1954418630} ## Changelog: [Internal] - Generate React Native specific code inside React Native Reviewed By: cortinico, blakef Differential Revision: D65541505 fbshipit-source-id: 1412d7f23c4d2230b795af41f1e832c8a70d5859
…ebook#47474) Summary: When running the commands to check the flow types locally, there is quite some noise from files under `packages/rn-tester/Pods` that should not be checked as they are not from the source code itself. <img width="839" alt="Screenshot 2024-11-07 at 00 50 55" src="https://github.com/user-attachments/assets/7ad3d96d-0f4a-4772-9e37-34d7e593b4cf"> ## Changelog: [INTERNAL] [FIXED] - Excluding `packages/rn-tester/Pods/` from flow checks Pull Request resolved: facebook#47474 Test Plan: ```bash yarn flow ``` Reviewed By: cortinico Differential Revision: D65594400 Pulled By: cipolleschi fbshipit-source-id: d5e8828f41fc87c9a95293c250f24673ebbc6cd4
Summary: Pull Request resolved: facebook#47481 The Codegenerated files has this option turned off. This is causing Xcode to output hundreds of warnings due to missing nullability options. RThis fixes them. ## CHANGELOG [Internal] - Set ASSUME_NONNULL regions in codegen'd files Reviewed By: dmytrorykun Differential Revision: D65596598 fbshipit-source-id: bbf664944e103c05ef593a7e07bf5b767445950c
Summary: Pull Request resolved: facebook#47482 XCBeautify swallow some errors, especially all the linker errors when some symbol is not defined. The full error is not available in the raw log either. This makes much harder to debug those issues when they happen. We can remove xcbeautify for the time being, while we find a better solution. ## Changelog [Internal] - Remove XCBeautify from ci Reviewed By: dmytrorykun Differential Revision: D65596745 fbshipit-source-id: 0550d4cbeadc5bec8acc61b5edc1320d3445bcaf
…47461) Summary: Pull Request resolved: facebook#47461 As titled, is overwritten later in the file. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D65546370 fbshipit-source-id: 4ea71d24e429b7bbded3e7bb7c75015a2c9d95d8
…circular dependency (facebook#47478) Summary: Pull Request resolved: facebook#47478 That's a reland of D65540601 The `UIManager.eventDispatcher` return type is wrong and is causing a breaking change in 0.77 For 0.76 we fixed it in the release branch but we should fix it for good in main as well. To solve it I had to fix the circular dependency between .bridge and .uimanager. I wish I could have isolated the .events package better but as everythign is public, any change we do is going to be a breaking change so I'm being over cautios here. Changelog: [Android] [Fixed] - Undo breaking change of UiManager.eventDispatcher return type Reviewed By: javache Differential Revision: D65595391 fbshipit-source-id: fc7f6dce78e531c5ec0cc493ed90c0012262b77f
Summary: Pull Request resolved: facebook#47419 Minor improvements to `ImageExample` so we log when images fail to load. Also replaces a `Text` component with `RNTesterText` so it's legible. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D65363864 fbshipit-source-id: 6c7ce8d5af6aabfed21479c784911bdcffe4684e
Summary: Pull Request resolved: facebook#47483 I relaized too late that there were a couple of comments on [facebook#47458](facebook#47458) to add some explanation/remove commented code. This change applies those comments ## Changelog [Internal] - Cleanup after landing [facebook#47458](facebook#47458) Reviewed By: dmytrorykun Differential Revision: D65597157 fbshipit-source-id: 238bb75e4b45efae9a8736a7b4feb10f5af5e3d9
Summary: Pull Request resolved: facebook#47475 Creates a feature flag to evalute the impact of disabling `InteractionManager` and replacing its scheduling behavior with `setImmediate`. Changelog: [Internal] Reviewed By: javache Differential Revision: D65577455 fbshipit-source-id: c0dc2b4d062eff4929ef37c5e217fd194addd790
Summary: Pull Request resolved: facebook#47479 Changelog: [Internal] Reviewed By: cortinico Differential Revision: D65595979 fbshipit-source-id: be8217ef1fd9f59af57a1e100a4d9e86b66d8027
…ebook#47488) Summary: Pull Request resolved: facebook#47488 As per title. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D65594248 fbshipit-source-id: 5a21baefb768b1c6f8ec0c33158812d1de6113d5
Summary: Pull Request resolved: facebook#47466 Now, when the useAlwaysAvailableJSErrorHandling feature flag is true, React Native will use the earlyjs c++ error reporting pipeline for handling all javascript errors! Changelog: [Internal] Reviewed By: javache Differential Revision: D64715159 fbshipit-source-id: 597a5278eb792f87dca10e06fa9816b3a8c47b84
Summary: Pull Request resolved: facebook#47470 Convert to Kotlin and formalize it being an internal class (some methods were already `protected` in Java) Changelog: [Android] [Breaking] - Stable API - Make SwipeRefreshLayoutManager internal Reviewed By: cortinico Differential Revision: D65481861 fbshipit-source-id: afc5c624373fbcd3ca2d28b2834d2682de672997
Summary: Pull Request resolved: facebook#47443 As part of sustainability week effort for switching to internal here: https://fb.workplace.com/groups/251759413609061/permalink/872342228217440/ Reducing visibility of ImageStoreManager from public to internal Changelog: [Android] [Breaking] - Stable API - Make ImageStoreManager internal Reviewed By: javache Differential Revision: D65520953 fbshipit-source-id: 0207be6a5e0b92dbbaee534735fc829e9202727d
…#47498) Summary: Pull Request resolved: facebook#47498 I am trying to help someone with creating a sticky header on a scrollview, specifically one that floats on the side of the scrollview instead of the top Currently we can't really do that, since utilizing `position: absolute` to layout this properly will get overriden by the header styles changed in this diff This was only added since static was the default and we needed to apply zIndex. With proper static implementation that is no longer the case, so I think it makes sense to remove this to support this use case. Changelog: [General] [Breaking] - `position` of sticky headers on `ScrollView` will now be taken into account Reviewed By: rozele Differential Revision: D65626544 fbshipit-source-id: 8d650ca7654918e692435935e7c1094c412fd9f6
…acebook#47502) Summary: Pull Request resolved: facebook#47502 Enables the two following feature flags: - `enableAnimatedAllowlist` - `enableAnimatedPropsMemo` The former enables the use of an experimental optimization to provide `unstable_createAnimatedComponentWithAllowlist` and `useAnimatedProps` an allowlist of props that reduces the set of props iterated over by to find props with `AnimatedNode` (e.g. `Animated.Value`) instance values. The latter enables improved memoization logic in `Animated` so that its intenal state is invalidated less frequently, reducing the cost of updating `Animated` components. Changelog: [General][Changed] - Optimized the performance of updating `Animated` components. Reviewed By: rozele Differential Revision: D65645985 fbshipit-source-id: 85f9e53072f09a59589d76d0c096f4cedd17bb4b
…acebook#47505) Summary: Pull Request resolved: facebook#47505 As per title. Changelog: [Internal] Reviewed By: tdn120 Differential Revision: D65596132 fbshipit-source-id: d08aea48ff293cc7f20ebc40a1d289dcb8158dcb
Summary: Pull Request resolved: facebook#47506 The Check nightlies job prepare a new nightly app with additional libraries and on iOS it builds with `yarn ios`. The command tries to launch the app on the simulator which sometimes fails and this can make the jobs keep running for hours. This change make sure that we only build the app ## Changelog: [Internal] - Only build iOS in CI for Check Nightlies Reviewed By: blakef Differential Revision: D65656812 fbshipit-source-id: 14db3738f33f8024c9e99fe206b170209154bac7
…7424) Summary: Pull Request resolved: facebook#47424 Changelog: [Internal] Reviewed By: cortinico Differential Revision: D65479614 fbshipit-source-id: d2ab86eb0e8c68a5733c602652b4b8dccc09a0a1
Summary: Pull Request resolved: facebook#47456 Changelog: [Internal] Reviewed By: tdn120 Differential Revision: D65486257 fbshipit-source-id: d18d38fd7e605918d79e370dda7df51abac2f23c
…7509) Summary: Pull Request resolved: facebook#47509 Fixes facebook#47504 Changelog: [Android] [Fixed] - RNGP - Do not attempt to substring to 1024 while logging Reviewed By: javache Differential Revision: D65659586 fbshipit-source-id: 8fa16131cea96b8b6aa9c0224c7b990a4f51175f
…book#47510) Summary: Pull Request resolved: facebook#47510 As per title. Changelog: [Internal] Reviewed By: tdn120 Differential Revision: D65598073 fbshipit-source-id: 401750f2df9bd434a8310f107f46a686bfa6601c
Summary: Pull Request resolved: facebook#47881 changelog: [internal] collapsable prop is not only for android. Reviewed By: NickGerleman Differential Revision: D66299356 fbshipit-source-id: 1c7435c77ef029fea55346f4ca16b5c81022b85a
Summary: Add changelog for 0.76.3 Changelog: [Internal] - Add changelog for 0.76.3 bypass-github-export-checks Pull Request resolved: facebook#47893 Test Plan: N/A Reviewed By: cipolleschi Differential Revision: D66329466 Pulled By: blakef fbshipit-source-id: e399175e198d11e2a5c0492fa1869797b50ef26f
Summary: Attempting to use the various bridging template and generated C++ Specs for native modules in a project compiling with MSVC does not build. For the fromJs I had to add `std::move` - otherwise it could not cast. The supportsFromJs and supportsToJs are changed to address an IntelliSense issue where the template specialization cannot have default members. ## Changelog: [GENERAL] [FIXED] - Fix C++ bridging template compatibility with MSVC Pull Request resolved: facebook#47882 Test Plan: It continues to build on Android/iOS builds. And it also builds with MSVC for react-native-windows and other out of tree platforms that use MSVC. Reviewed By: cipolleschi Differential Revision: D66360833 Pulled By: javache fbshipit-source-id: bf97db1cd247a383eb86cac31c601e8ab3400fd2
Summary: Fixes the high contrast color when not specified. Previously, if we didn't specify highContrastLight or highContrastDark, it would create a UIColor with an alpha of 0, which is not what we expected. We should fall back to the dark or light color instead. ## Changelog: [IOS] [FIXED] - Fabric: Fixes high contrast color when not specified Pull Request resolved: facebook#47418 Test Plan: 1. Enable color contrast in iPhone's settings. 2. Open PlatformColor example in RNTester. See dynamic colors 3. color shows correctly ![image](https://github.com/user-attachments/assets/a71b8743-b397-4a11-b287-ec117b1ba243) Before: ![image](https://github.com/user-attachments/assets/6a12824b-f77c-4979-a232-c1c97554e53c) Reviewed By: javache Differential Revision: D66303078 Pulled By: cipolleschi fbshipit-source-id: 63a0d2bc94eea438d4f69643d09825b74575188b
Summary: Pull Request resolved: facebook#47680 This was deprecated in D50128456 so should be safe to remove now. Changelog: [Android][Removed] Removed TurboReactPackage, which was replaced by BaseReactPackage Reviewed By: mdvacca Differential Revision: D66127067 fbshipit-source-id: a4090ab439cf99dc693622b8da2c0cffa247ad24
Summary: Pull Request resolved: facebook#47681 These were deprecated back in D49262824, so should be safe to remove now. Changelog: [Android][Removed] Removed hasConstants constructor from ReactModuleInfo Reviewed By: mdvacca Differential Revision: D66127070 fbshipit-source-id: 3bd441c96597598470f16c7770c4dfa4ada563a0
…oid emulators (facebook#47880) Summary: Pull Request resolved: facebook#47880 The previous diffs in this stack have aimed to make URL rewriting by inspector-proxy robust to any configuration of device->server, debugger->server and server->server connections. Though rewriting was originally introduced to support Android emulator networking, we can now expand it to cover other use cases, like the device reaching the server over an internet address not reachable from the dev machine, or the debugger routing to the server through a tunnel on a different port, without needing CORS workarounds. Changelog [General][Fixed] dev-middleware: Rewrite URLs in the inspector proxy to cover all configurations, not just Android emulators. Reviewed By: huntie Differential Revision: D66247355 fbshipit-source-id: e9201ebc1f7f5fe2119c71cd4d7b4ca895645404
Summary: Pull Request resolved: facebook#47674 Small changes that can be done in Java and make a Kotlin conversion more seamless. Changelog: [Internal] Reviewed By: javache Differential Revision: D66033963 fbshipit-source-id: 666302f132b98019f1013a335a2c59c7a4f31836
Summary: Pull Request resolved: facebook#47878 Make it clearer what we're checking, and provide a single point of code where we could potentially improve the logic. Changelog: [Internal] Reviewed By: rshest Differential Revision: D66302526 fbshipit-source-id: a0e6d1004aef25897e9633fe930915ba585c1cb5
Summary: Pull Request resolved: facebook#47890 The fix in [facebook#40859](facebook#40859) overrode every possible add or remove to ensure completeness, but all paths should also call onViewAdded/onViewRemoved via: - `addView`/`addViewInLayout` -> [addViewInner](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r5/core/java/android/view/ViewGroup.java#5310) - `removeView`/`removeViewInLayout` -> [removeViewInternal](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r5/core/java/android/view/ViewGroup.java#5606) - `removeViews`/`removeViewsInLayout` -> [removeViewsInternal](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r5/core/java/android/view/ViewGroup.java#5714) Changelog: [Android][Changed] Consolidated ReactViewGroup add/remove overrides Reviewed By: javache Differential Revision: D66320586 fbshipit-source-id: aaf16af5ad87789f575fcb79dcf31f5686002b2d
…ercentThreshold) (facebook#47908) Summary: Pull Request resolved: facebook#47908 Changelog: [General][Added] - Add support for `rn_rootThreshold` in Intersection Observer `rn_rootThreshold` is a custom IntersectionObserver option and not part of the IntersectionObserver spec. We are adding it because it covers a specific use-case for measuring viewability that is robust for `target`s that are larger than the viewport or specified `root`. The threshold ratio is of the intersection area (of `root` and `target`) to the total area of the `root`. {F1960832959} Source - EX314979 `rn_rootThreshold` is an optional threshold and can be combined with the `thresholds` option. An intersection will fire if any specified thresholds is met. Note: If you use specify a `rn_rootThreshold`, the default `threshold` is no longer applied The main use case of `rn_rootThreshold` is being able to specify a level of viewability independent of `target` size. For example, a `target` that is larger than the `root` (commonly the viewport) will not trigger the IntersectionObserver for a `threshold` of `1`. Setting `rn_rootThreshold` of `1`, will trigger once the item takes full size of the `root`.'; Reviewed By: yungsters Differential Revision: D66031119 fbshipit-source-id: 7bdc871dc5b4e6c0edc7d6e17a0a0cfd51c4fe81
…book#47897) Summary: Pull Request resolved: facebook#47897 Changelog: [Internal] In some situations, we want to provide multiple `CxxReactModules` from a single lambda. Currently, this is painful -- this change makes it less so. Reviewed By: tdn120 Differential Revision: D66337573 fbshipit-source-id: ed57ad6ca2b98d4787aca7da3714c05c3d03b649
…vity is the one being destroyed (facebook#47907) Summary: Changelog: [Internal] Pull Request resolved: facebook#47907 EnableDevSupport is set to false on lifecyle events like onPause and onHostDestroy, and set to true on events like onResume and onCreate. In apps like AMA and Twilight, there is first a loginActivity, which then calls the mainActivity. After mainActivity is created, loginActivity is destroyed. This causes enableDevSupport to always be false because onDestroy for loginActivity is triggered after onCreate for mainActivity. Reviewed By: RSNara, alanleedev Differential Revision: D66124018 fbshipit-source-id: e40a5b24cf73000b0bfeaa1d8e3902718b281410
Summary: Pull Request resolved: facebook#47891 Various C++ utilities for handling callbacks and promises rely on the static LongLivedObjectCollection. Even if a host platform injects it's TurboModuleBinding with a custom LongLivedObjectCollection, there's no guarantee that the platform is not also using C++ TurboModules that use the static LongLivedObjectCollection. Clearing both collections solves issues for TurboModuleBindings with custom LongLivedObjectCollections that also have cross platform C++ TurboModules that use the static collection. ## Changelog [Internal] Reviewed By: javache Differential Revision: D66324044 fbshipit-source-id: a5a973087c35fc00240e40ba757d49125473daf4
Summary: Pull Request resolved: facebook#47910 It seems there could be a race where a commit is being processed on the JS thread after the surface has been removed from the mounting manager. Since we don't actually need to retrieve the default paddings in these cases, there's no reason we need an enforced read of the SurfaceMountingManager. ## Changelog [Internal] Reviewed By: javache Differential Revision: D66369969 fbshipit-source-id: 44ccdc9beafdbd0ac47457fb01c4114348c1a316
Summary: Pull Request resolved: facebook#47906 There are no usages in the repo. External usages should be using [BackgroundStyleApplicator](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/BackgroundStyleApplicator.kt#L82). Changelog: [Android][Breaking] Removed ReactViewGroup.getBackgroundColor() Reviewed By: NickGerleman Differential Revision: D66368623 fbshipit-source-id: bf173efc7e40d3d8a5d55ba0f82eed49b4cb2746
…cebook#47745) Summary: Pull Request resolved: facebook#47745 Remove DeprecatedInNewArchitecture for ReactPropHolder annotation ReactProp is still used in new arch, we might remove this annotation in the future but it will be independent of new arch changelog: [internal] internal Reviewed By: javache Differential Revision: D66216729 fbshipit-source-id: 3f64858ab4fa60b09978b18b17200ae488e229ce
…acebook#47746) Summary: Pull Request resolved: facebook#47746 Remove DeprecatedInNewArchitecture annotation from ReactPropGroup since this annotation is not deprecated in new arch changelog: [internal] internal Reviewed By: javache Differential Revision: D66216727 fbshipit-source-id: 252bae58557b51c9fbfb1deab4edc7c50511a005
Summary: Pull Request resolved: facebook#47747 Deprecate NotThreadSafeViewHierarchyUpdateDebugListener as won't be available in new arch and will be deleted changelog: [internal] internal Reviewed By: javache Differential Revision: D66216730 fbshipit-source-id: 88f3346ad38b80a710d9df4ba08b63887048c8cd
Summary: Pull Request resolved: facebook#47914 This was a bug in the original diff: D66193194. If a fatal js error happens, we should only drop subsequent **fatal** js errors. It's fine to report soft errors. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D66392706 fbshipit-source-id: c51bae186184c54faa9bce065b81b442607e751b
Summary: Pull Request resolved: facebook#47912 Changelog: [Internal] Reviewed By: SamChou19815 Differential Revision: D66379853 fbshipit-source-id: 3a7677c5a71ef74e509ed43be87e455aed0cbaa7
…#47918) Summary: I was just going through the README file, and I felt that the word "repo" seems a bit informal. Thus I made the correction and made it "repository". ## Changelog: [General] [Changed] - Fixed a typo in the README file. Pull Request resolved: facebook#47918 Test Plan: No specific Test Plan for these changes, as it is just a typo fix in README.md Reviewed By: fkgozali Differential Revision: D66414686 Pulled By: arushikesarwani94 fbshipit-source-id: 578530d2dcdf046a90bf5a5bc32ba68e8f496c81
…kground (facebook#47336) Summary: Pull Request resolved: facebook#47336 Before mix-blend-mode would not blend with the background color due to it not being a ViewGroup. This adds the mix-blend-mode logic to ReactRootView so blending works Changelog: [Android][Fixed] - Enable mix-blend-mode on ReactRootView so blending works with app background Reviewed By: NickGerleman Differential Revision: D65156543 fbshipit-source-id: b3628b667573d0b56c74214e40d21c656fda495a
…7896) Summary: Pull Request resolved: facebook#47896 X-link: facebook/yoga#1752 These APIs were only added so that we could do TDD as we work on intrinsic sizing functionality. As of right now they do nothing. We are aiming on publishing a new version of Yoga soon so for the time being we are going to back these out so as not to confuse anyone with this new functionality. Ideally we get to a point where we have some temporary experimental header to stage these in but this is a bit time sensitive so just backing out for now Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D66332309 fbshipit-source-id: 793f77dad021fa5e57b52c36ae954307636bcbf0
… keywords" (facebook#47895) Summary: Pull Request resolved: facebook#47895 X-link: facebook/yoga#1750 These APIs were only added so that we could do TDD as we work on intrinsic sizing functionality. As of right now they do nothing. We are aiming on publishing a new version of Yoga soon so for the time being we are going to back these out so as not to confuse anyone with this new functionality. Ideally we get to a point where we have some temporary experimental header to stage these in but this is a bit time sensitive so just backing out for now Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D66332307 fbshipit-source-id: 1d596964e0c893091c541988506e8b80fa6d1957
This PR didn't actually merge up to 0.77.0, seems to have been marked as merged when I merged #2333 . I'l make a new PR to merge 0.77.0 to |
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:
Merge up to
0.77.0
, along with a couple of commits to get a ruby fix + update the pod file.Test Plan:
CI should pass. Expect a manual release afterwards.