PR test rmq #39471
Closed
PR test rmq #39471
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
…ok#38830) Summary: Pull Request resolved: facebook#38830 Changelog: [Internal] - Add example with side effect in render got triggered directly Reviewed By: rshest Differential Revision: D48055836 fbshipit-source-id: 8bf596165741bde93cf44cd96b93fb2efaea1b13
Summary: Pull Request resolved: facebook#38963 This diff refactors `hermes-utils.rb` in the following way: - Explicitly define all the scenarios how `hermes-engine.podspec` can consume its source. - Try to be explicit and verbose about when those scenarios take place. - Split `compute_hermes_source` into two functions: - `hermes_source_type` that determines the podspec source type. - `podspec_source` that builds the podspec source based on the source type provided. Also `hermes-engine.podspec` now uses source type returned by `hermes_source_type` instead of derived values `:git` and `:http`, which were not descriptive and granular enough. This refactoring should make adding new cases and altering existing ones easier. Conditions, precedence and how to act for each scenario is much more explicit. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D48161239 fbshipit-source-id: 3d3d24aa1e05458e1f877153e43ebc2b437352e9
Summary: Pull Request resolved: facebook#38967 Changelog: [IOS][Added] - Now it is possible to build Hermes form local source directory. Just set REACT_NATIVE_OVERRIDE_HERMES_DIR to the path to that directory. Known shortcoming: changes made to the Hermes source will not be reflected in the RN project. You should manually delete `Pods/hermes-engine` and rerun `pod install`. Reviewed By: cipolleschi Differential Revision: D48121314 fbshipit-source-id: 0389662396921bdf120d390de36a586c52eb47f1
Summary: Pull Request resolved: facebook#39055 ## Changelog: [Internal] - Remove unused imports ## Facebook: Reviewed By: sammy-SC Differential Revision: D48429794 fbshipit-source-id: 1473aeaad08f7a38908d0b43d52a644b31affdd1
Summary: Pull Request resolved: facebook#39056 ## Changelog: [Internal] - Reduce header dependencies in RuntimeScheduler ## Facebook: Reviewed By: sammy-SC Differential Revision: D48429842 fbshipit-source-id: 2466d7136a668d0a814c6d80dcec10e782452238
Summary: Pull Request resolved: facebook#39058 ## Changelog: [iOS][Changed] - Extract RuntimeScheduler as separate cocoapod dependency ## Facebook: Reviewed By: sammy-SC Differential Revision: D48429964 fbshipit-source-id: 179d957515d15487197163a664f6ae6ec493f908
Summary: Pull Request resolved: facebook#39057 ## Changelog: [iOS][Changed] - Use the runtime scheduler in the old Architecture ## Facebook Reviewed By: sammy-SC Differential Revision: D48430129 fbshipit-source-id: ed1a1d27da531ba01b46afdd9d33213aea6bdeee
Summary: Pull Request resolved: facebook#39136 ## Changelog: [Internal] - `getConstants()` method for TM was enforced to only use object literals for the return type specs. This limits flexibility, in particular those data structures can't be consequently exported and picked up by codegen (not even mentioning the potential need for copypasting those obejct literals around). This relaxes this restriction. Note that I've been digging into the development history in order to find out whether there was any particular historical reason for such a limitation, but couldn't find any, so I assume it was rather incidental. Reviewed By: christophpurrer Differential Revision: D48620652 fbshipit-source-id: 92d6ba531fc99fb9b25b4957ae123e7832f44ee4
Summary: Pull Request resolved: facebook#39131 Docs on the new behavior: https://flow.org/en/docs/react/multiplatform Changelog: [Internal] Reviewed By: samwgoldman Differential Revision: D48085422 fbshipit-source-id: daaa5a7d7d04871ab3da1ad47c6b88ef4226bdfd
Summary: Pull Request resolved: facebook#39146 Adds Microsoft Edge fallback for the `/open-debugger` endpoint when no Chrome installation is found. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D48563386 fbshipit-source-id: 74baba7c03a062bd769b2f9ac0cc35bac0b2ae65
Summary: Pull Request resolved: facebook#39151 Changelog: [Internal] This typo in the condition prevented correspeponding code block form executing ever. Reviewed By: cipolleschi Differential Revision: D48648118 fbshipit-source-id: f78291b79182b0f0a6183528dce02e091c2194ae
Summary: Pull Request resolved: facebook#39142 X-link: facebookresearch/playtorch#227 `ReactNativeConfig.java` -> `ReactNativeConfig.kt` changelog: [internal] internal Reviewed By: rshest Differential Revision: D48585508 fbshipit-source-id: 46035062662eeebddf546814dbcef239e769e17f
Summary: X-link: facebook/litho#954 Pull Request resolved: facebook#39132 X-link: facebook/yoga#1347 # Context Reviewed By: NickGerleman, astreet Differential Revision: D48607502 fbshipit-source-id: 79552bc76879d1fc15341423ae6fbadeab2fb7af
…ook#39135) Summary: Pull Request resolved: facebook#39135 ## Changelog: [Internal] - Expose constants type from DeviceInfo native module - this makes codegen generate the corresponding data structure, making the native module implementation shorter (in C++ in particular). Reviewed By: christophpurrer Differential Revision: D48620784 fbshipit-source-id: 40ae83ebec92e0a470c20ef1ad16f8392e2bf8b0
Summary: Pull Request resolved: facebook#39137 getNativeModuleIterator is not required to be public, reducing visibillity to package only changelog: [internal] intenral Reviewed By: philIip, rshest Differential Revision: D48588376 fbshipit-source-id: 6cbff90a4c51d2af4b0693b84c1a674ea24b94d1
Summary: Pull Request resolved: facebook#39139 EZ cleanup of TurboReactPackage changelog: [internal] internal Reviewed By: cortinico Differential Revision: D48588377 fbshipit-source-id: 5645acad938a4ebf84b81818dd0a915cc86a2682
Summary: Pull Request resolved: facebook#39140 TurboReactPackage.getModule is nullable, although the internals of ReactNative requires this method to be non null (otherwise there will a NPEs) I'm making TurboReactPackage.getModule no nullable, this is important to simplify API and future migration to kotlin changelog: [internal] internal/ Reviewed By: cortinico Differential Revision: D48588375 fbshipit-source-id: e510f76ea0271ff33ab2ebe6c76382c4781e1787
Summary: Pull Request resolved: facebook#39153 `FlatList`'s restriction on not changing the `onViewableItemsChanged` prop forces developers to violate the rules of React, risking bugs and blocking the rollout of other improvements such as React Forget. This diff relaxes the validation specifically for the seemingly common case in which a developer passes just a onViewableItemsChanged prop instead of viewabilityConfigCallbackPairs. We use an anonymous closure to create a stable identity that will be passed down to the underlying VirtualizedList, where the closure calls the current `props.onViewableItemsChanged`. The intent of this diff is to alleviate the worst impacts of the current restriction with a correct if not ideal solution, giving us time to fix the API more holistically. Feedback welcome! ## Changelog: [Changed] - Allow passing different values to `FlatList.onViewableItemsChanged` ## Facebook See https://fburl.com/workplace/9svfrytw for more context. Reviewed By: NickGerleman Differential Revision: D48656586 fbshipit-source-id: 5b0926deada25637786c4cf3b329607d9f515528
Summary: Pull Request resolved: facebook#39155 [Changelog]: [Android][Fixed] Fix crash in CompositeTurboModuleManagerDelegate CompositeTurboModuleManagerDelegate.cpp crashes as we pass in one or multiple ``` jni::alias_ref<TurboModuleManagerDelegate::javaobject> delegate ``` but don't retain a global reference to them. Fix use: ``` jni::make_global(delegate) ``` Differential Revision: D48670217 fbshipit-source-id: e805f28919918b2a867589dbb6e2a70d67dcd8c3
Differential Revision: D48588375 Original commit changeset: e510f76ea027 Original Phabricator Diff: D48588375 fbshipit-source-id: 62c8b062c8316bb7a90fced6390eb20f8274ea88
Differential Revision: D48588377 Original commit changeset: 5645acad938a Original Phabricator Diff: D48588377 fbshipit-source-id: e0da38e5b721d6bfc7fd6b4607c7712301330a8f
Differential Revision: D48588376 Original commit changeset: 6cbff90a4c51 Original Phabricator Diff: D48588376 fbshipit-source-id: 79b481b9784709e20074cda2d16605369568fc84
Summary: Given that the e2e tests are quite flaky, we want to reduce the flakyness making them non land blocking. The idea is to: 1. always have them green in CircleCI 2. store the test logs in CircleCI artifacts, so we can explore them if needed. 3. use danger to read the artifacts from CircleCI and post a message to inform the user whether the Test ends up successfully or not. ## Changelog: [Internal] - Make e2e tests non land-blocking. Use Danger to report the status of the E2E jobs Pull Request resolved: facebook#39129 Test Plan: CircleCI stays green, logs are uploaded as artifacts. Reviewed By: rshest Differential Revision: D48642955 Pulled By: cipolleschi fbshipit-source-id: 185862f46c47d59f949743a9b893162b2bb3a651
facebook#39149) Summary: Pull Request resolved: facebook#39149 Props structs are allowed to references RawValue keys multiple times, however this didn't work correctly if the key was formed out of a different combination of prefix/name/suffix, as the duplicate key entry would've been removed from the `RawPropsKeyMap`. Log an error in such scenarios to help identify these types of problems. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D48641819 fbshipit-source-id: 8cf71366cbf8ae6bee418a6c9d030ebd38784d52
Summary: Expose a `unstable_browserLauncher` option to `createDevMiddleware()`. This allows integrators to provide a custom implementation for opening URLs in a web browser, initially a `launchDebuggerAppWindow` method. Customising the browser launcher implementation can be useful in cases where the dev server is running remotely and not on the developer's local machine. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D48647750 fbshipit-source-id: ebf34106ad27899024396b13b22ec4536aad05b9
…error reporting (facebook#39144) Summary: Pull Request resolved: facebook#39144 ## Changelog: [Internal] - This adds more information into internal shadow tree consistency check error reporting, as well as some minor code refactorings. Note that the code is run only in debug, and normally you don't trigger such issues, unless you look into a new platform implementation (which I did). Reviewed By: javache Differential Revision: D48643602 fbshipit-source-id: a6475f2f577c7b461622472af1c6855072ae319e
… traits (facebook#37649) Summary: - when using the `useWindowDimensions()` hook in a component, it's possible for the hook to report incorrect sizes and not update as frequently as it should - this is most applicable to apps built for iPad and macOS - closes facebook#36118 ### Existing Behavior - https://youtu.be/NcV6kEDg20E - either when resizing a React Native app to a different [Size Class](https://developer.apple.com/design/human-interface-guidelines/layout#Device-size-classes) or changing the Appearance, we dispatch an `RCTUserInterfaceStyleDidChangeNotification` notification - these are then handled in the `interfaceFrameDidChange` method of `RCTDeviceInfo` - this results in a `didUpdateDimensions` Device Event, which in turn updates the results of `useWindowDimensions()` - see [RCTDeviceInfo.mm#L217-L232](https://github.com/facebook/react-native/blob/v0.72.0-rc.4/packages/react-native/React/CoreModules/RCTDeviceInfo.mm#L217-L232) - and [Dimensions.js#L119-L124](https://github.com/facebook/react-native/blob/v0.72.0-rc.4/packages/react-native/Libraries/Utilities/Dimensions.js#L119-L124) 🐛 **However** 🐛 - if you are resizing without triggering a `UITraitCollection` change, the Dimensions reported by `useWindowDimensions()` can become stale, until you either:- - hit a certain width that is considered a different Size Class - change the Appearance - background then resume the app - make the app full-screen ### Changed Behavior - https://youtu.be/w9BevpZ2y08 - added a new `RCTRootViewFrameDidChangeNotification` notification - the thinking here is to avoid additional overhead by re-using the same `RCTUserInterfaceStyleDidChangeNotification` - maybe it's overkill? - the new notifications are sent from an override of `setFrame` on `RCTRootView` - the new notifications call the same `interfaceFrameDidChange` method of `RCTDeviceInfo` - Dimensions are now reported correctly when resizing; even within the same Size Class ## Changelog: <!-- Help reviewers and the release process by writing your own changelog entry. Pick one each for the category and type tags: [ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message For more details, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [IOS] [FIXED] - Dimensions could be reported incorrectly when resizing iPad or macOS apps Pull Request resolved: facebook#37649 Test Plan: **Reproduction: https://github.com/jpdriver/Dimensions** or to recreate it yourself:- - Generate a new project - Change App.tsx ``` import * as React from 'react'; import {View, Text, useWindowDimensions} from 'react-native'; export default function App() { const {width, height} = useWindowDimensions(); return ( <View style={{flex: 1, justifyContent: 'center', alignItems: 'center'}}> <Text>Width: {width}</Text> <Text>Height: {height}</Text> </View> ); } ``` - Open the iOS project in Xcode and enable iPad support - Enable the iPad app to be used in any orientation - Run the app - Enable Stage Manager - Drag one of the corners to resize the app Reviewed By: javache Differential Revision: D46335537 Pulled By: NickGerleman fbshipit-source-id: 1533f511cf3805fdc9629a2ee115cc00e204d82c
Summary: Chronos Job Instance ID: 1125907940502274 Sandcastle Job Instance ID: 9007200283452584 allow-large-files ignore-conflict-markers opt-out-review Differential Revision: D48713231 fbshipit-source-id: eb5fbaeda1a4e8ea9bce81e7c490fabb9bd0a36e
…#39158) Summary: Pull Request resolved: facebook#39158 .flowconfig.android is the same as .flowconfig now. The check is meaningless. This diff removes it and the flowconfig. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D48629137 fbshipit-source-id: bc1bee9426eed7bc41dc7a1efe75333e1191e066
Summary: Chronos Job Instance ID: 1125907940517829 Sandcastle Job Instance ID: 31525198421678702 allow-large-files ignore-conflict-markers opt-out-review Differential Revision: D48717880 fbshipit-source-id: 5200b8b0bc5311b776fc8ff6f6d17a8204efa5b7
Summary: Pull Request resolved: facebook#39336 We are introducing the new getModule method into the ReactPackage interface following the "Registration of Native Modules" design This method defaults to true with the goal to avoid compatibility breakage changelog: [Android][Changed] Introducing getModule method into ReactPackage interface, defaulting to null. This method will be used in the Stable API of React Native Reviewed By: cortinico Differential Revision: D48992720 fbshipit-source-id: 4ecc93bc84daa8903a4d9a1cf6ced60adb78f153
Summary: Pull Request resolved: facebook#39351 In this diff I'm introducing the new WillBeDeprecatedInNewArchitecture annotation, the goal of this annotation is to describe that a class or method will be deprecated when the new architecture of react native is fully rolled out in OSS. changelog: [Android] Introduce WillBeDeprecatedInNewArchitecture annotation Reviewed By: cortinico Differential Revision: D49068234 fbshipit-source-id: 4c5ce25b3fbcc2d7545f2000d931be893a661332
…le instead (facebook#39339) Summary: Pull Request resolved: facebook#39339 Deprecating createNativeModules method from ReactPackage interface recommending using getModule instead in the new architecture of React Native changelog: [Android][Changed] Deprecating createNativeModules method from ReactPackage interface recommending using getModule instead in the new architecture of React Native Reviewed By: cortinico Differential Revision: D48992719 fbshipit-source-id: b20de9274ed4bd35a239c672b52bfac529a79bc2
Summary: Pull Request resolved: facebook#39337 Mark ReactPackage.getModule as UnstableReactNativeAPI changelog: [internal] internal Reviewed By: arushikesarwani94 Differential Revision: D49068233 fbshipit-source-id: 56be5c08eaa5b33c069e540ba452dba30111a64f
Summary: Pull Request resolved: facebook#39338 Fix lint warning in MainReactPackage, as reactModule could be null changelog: [internal] internal Reviewed By: cortinico Differential Revision: D49077064 fbshipit-source-id: 34e04cac1a8875af94bbb78119a323c6319b6d6b
Summary: Pull Request resolved: facebook#39342 Annotate HybridData with DoNotStrip The stack of diffs aims to introduce new features and deprecate old ones in the React Native Android architecture. The main goal is to make the architecture more stable and easier to use for developers. The changes include marking ReactPackage as NullSafe, introducing the new getModule method, introducing the WillBeDeprecatedInNewArchitecture annotation, deprecating createNativeModules and marking getModule as UnstableReactNativeAPI, and fixing a lint warning in MainReactPackage. # This diff This diff is adding the annotation `DoNotStrip` to the `HybridData` field in the `NativeMethodCallInvokerHolderImpl` and `CallInvokerHolderImpl` classes. This is to prevent the Android ProGuard optimizer from stripping the `HybridData` field, which is necessary for the proper functioning of the TurboModule system in React Native. Additionally, the `BUCK` file for the `core` module is updated to include the `androidx:annotation` and `com.facebook.proguard.annotations:annotations` dependencies. changelog: [intenral] internal# Context Reviewed By: cortinico Differential Revision: D49077065 fbshipit-source-id: cb36c0a11bdb8f5f0f4eaa7db1f0c9dcb3be2341
Summary: Pull Request resolved: facebook#39352 Reduce visibility of TurboModuleInteropUtils to package only changelog: [intenral] internal Reviewed By: cortinico Differential Revision: D49077066 fbshipit-source-id: b462e42e323f65aabde6206fa403b2faef491490
Summary: Pull Request resolved: facebook#39340 Reduce visibility of TurboModulePerfLogger to pacakge and remove some lint warns changelog: [intenral] internal Reviewed By: christophpurrer Differential Revision: D49077068 fbshipit-source-id: 9fe3c65f72003b09ca412e0aa37bf132cf3daee2
Summary: Pull Request resolved: facebook#39341 Use lambdas to return reactModuleInfoMap changelog: [intenral] internal Reviewed By: christophpurrer Differential Revision: D49077067 fbshipit-source-id: edd2e044cb258a7bc1597ece38836fc447758694
…ebook#39430) Summary: Pull Request resolved: facebook#39430 Changelog: [Internal] Reviewed By: javache Differential Revision: D49162188 fbshipit-source-id: ec9dbd3561ceb3d142b78475a41368f598003c32
…ableProps (facebook#39431) Summary: Pull Request resolved: facebook#39431 Changelog: [Android][Breaking] - Do not enable `excludeYogaFromRawProps` feature flag, if you need to pass layout props to Java view managers when using new architecture [Internal] Reviewed By: NickGerleman Differential Revision: D49114771 fbshipit-source-id: 171dfceef61d9851094465be8ff4eb9a87a3ab8f
Summary: Pull Request resolved: facebook#39457 ## Changelog [Android][General] - hasConstants in ReactModuleInfo does nothing now we can get rid of this. currently, the default value of hasConstants true, and the only library setting this value to false is `WebSocketModule`. this value is only read in bridge mode - it is an optimization that will not initialize the constants dictionary for native modules in bridge. however, we have plenty of native modules that don't provide constants that have not set this flag, so this is only turned on for `WebSocketModule`, which is probably not moving anything significant. i would recommend we get rid of this to simplify the ReactModuleInfo deprecation plan. Reviewed By: cortinico Differential Revision: D49210251 fbshipit-source-id: c82c997e01cd8012b2c1a5c3c36061f81799eb04
Summary: Pull Request resolved: facebook#39458 ## Changelog [Android][Deprecated] - hasConstants in ReactModuleInfo is marked as deprecated getting rid of `mHasConstants` ivar here and marking the getter as deprecated Reviewed By: cortinico Differential Revision: D49262577 fbshipit-source-id: 5394281bdc4a315ffc0d1debfaef1808dc6f4299
Summary: X-link: facebook/yoga#1380 Pull Request resolved: facebook#39433 Back when rolling out flex gap, we encountered a bug where gap was added to the end of the main axis when a size was not specified. During flex line justification/sizing, we calculate the amount of space that should be in between children. We erroneously add this, even after the last child element. For `justify-content`, this space between children is derived from free space along the axis. The only time we have free space is if we had a dimension/dimension constraint already set on the parent. In this case, the extra space added to the end of the flex line is usually never noticed, because we bound `maxLineMainDim` to container dimension constraints at the end of layout, and the error doesn't effect how any children are positioned or sized. There was at least one screenshot test where this issue showed up though, and I was able to add a slightly different repro where we may have free space without a definite dimension by enforcing a min dimension and not stretching. {F1091401183} The new reference is correct, and looking back at diffs, is what this seemed to originally look like when added three years ago. Seems like there may have been a potential regression, but I didn't spot anything suspicious when I looked around the code history. `betweenMainDim` may still be set for `gap` even if we don't have a sized parent, which makes the extra space propagated to `maxLineMainDim` effect parent size. Because we were in a code freeze, I opted to have us go with a solution just effecting flex gap, instead of the right one, in case there were any side effects. This cleans up the code to use the right calculation everywhere, and fixes a separate bug, where `endOfLineIndex` and `startOfLineIndex` may not be the last/first in the line if they are out of the layout flow (absolutely positioned, or display: none_ See the original conversation on facebook/yoga#1188 Reviewed By: javache Differential Revision: D49260049 fbshipit-source-id: 218552c5ff938668b9f257df7a1493e13ded4d0d
Summary: X-link: facebook/yoga#1384 Pull Request resolved: facebook#39446 This adds logic to the enum generator to generate C++ style scoped enums. This gives us a few nicities over C enums, even if both must exist: 1. We can add types and keep unsgined enums directly in bitfields 2. Style/readability 3. Avoiding implicit int conversion Reviewed By: rozele Differential Revision: D49267996 fbshipit-source-id: 1c41164c377b317c1fef97811c46cbc00b5a837e
Summary: Pull Request resolved: facebook#39450 X-link: facebook/yoga#1383 This converts usages of YGNodeType to NodeType Reviewed By: rozele Differential Revision: D49269117 fbshipit-source-id: 27318279fe555c28c605625a160d5be781b662b8
Summary: Pull Request resolved: facebook#39448 X-link: facebook/yoga#1386 This converts usages of YGExperimentalFeature to ExperimentalFeature Reviewed By: rozele Differential Revision: D49269440 fbshipit-source-id: 0fcb4f380e214a6aadcac457df5a989789bb05d2
Summary: Pull Request resolved: facebook#39451 X-link: facebook/yoga#1388 This converts usages of YGErrata to Errata Reviewed By: rozele Differential Revision: D49270354 fbshipit-source-id: 39c0d26a1609cca0a96da843796ab41c81e3af93
Summary: X-link: facebook/yoga#1387 Pull Request resolved: facebook#39447 This converts usages of YGLogLevel to LogLevel Reviewed By: rozele Differential Revision: D49270695 fbshipit-source-id: 2ba5b4f2b0af93fef89dbbb2ce54c2f486670aac
Summary: Pull Request resolved: facebook#39449 X-link: facebook/yoga#1385 This converts usages of YGPrintOptions to PrintOptions Reviewed By: rozele Differential Revision: D49270929 fbshipit-source-id: ad98dd25865138808d25b48eff22fbe81ccdd352
Summary: Pull Request resolved: facebook#39452 X-link: facebook/yoga#1389 This converts usages of YGMeasureMode to MeasureMode Reviewed By: rozele Differential Revision: D49271165 fbshipit-source-id: 273c9ed0a61c3965e469548d29d37e4566c974dc
Summary: Pull Request resolved: facebook#39463 Fix lint warning changelog: [intenral] internal Reviewed By: rshest Differential Revision: D49172556 fbshipit-source-id: 9e9543d3f9a507258f1c9466782234a3334cef75
…acebook#39461) Summary: Pull Request resolved: facebook#39461 In this diff I'm creating an empty constructor on ReactPackageTurboModuleManagerDelegate. This will be used in the next diffs of the stack. I'm also resorting methods for better read of the class changelog: [intenral] internal Reviewed By: arushikesarwani94 Differential Revision: D49172554 fbshipit-source-id: 54073c86c87aa145b12e783d8d8f75cd1f5b228c
Summary: Pull Request resolved: facebook#39462 In this diff I'm introdcuing the new UnstableAPI called LazyTurboModuleManagerDelegate. The goal of this class is to provide a Lazy registration of TurboModules without relying on ReactModule annotations neither the TurboReactPackage#getReactModuleInfoProvider method. This is not the final implementation, it's just a prototype that will be used to experiment and learn about perf implications. This class will be used in the next diffs of the stack changelog: [intenral] internal Reviewed By: cortinico Differential Revision: D49172555 fbshipit-source-id: 1609c523e6e72f2aa42ca7cc35e9170104a101db
Summary: Pull Request resolved: facebook#39454 1. Build with C++ 20 everywhere. 2. Update folly in OSS build to avoid a warning, and let us opt out of heavy bits required for supporting coroutines (we are still more than a year behind). 3. Update the folly podspec for the new version of folly 4. Update the many, many, copy/pasted header search paths for folly dependencies to be able to resolve fmt, now exposed to folly headers 4. Replaces a deprecated atomic usage with equivalent. 5. Fixes a deprecated implicit capturing `this` by value in lambda (same behavior, added a TODO because it seems sus) Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D49271685 fbshipit-source-id: 16610f7bcd1032d5796cc11f1cfa92a33d8c2593
…k#37766) Summary: This is a reopened version of facebook#35224 by isidoro98 which was closed without explanation, updated to resolve new merge conflicts and now includes an example in the RN-Tester app. Aside from that it is unchanged. Here is isidoro98's description from their original PR: This PR builds on top of facebook#31402, which introduced the `automaticallyAdjustsScrollIndicatorInsets` functionality. It aims to fix one of RN's longstanding pain point regarding the keyboard. The changes provide a better way of handling the `ScrollView` offset when a keyboard opens. Currently, when a keyboard opens we apply an **offset** to the `Scrollview` that matches the size of the keyboard. This approach is great if we are using an `InputAccessoryView` but if we have multiple `TextInputs` in a `ScrollView`; offsetting the content by the size of the keyboard doesn't yield the best user experience. ## Changelog: [iOS] [Changed] - Scroll `ScrollView` text fields into view with `automaticallyAdjustsScrollIndicatorInsets` Pull Request resolved: facebook#37766 Test Plan: The videos below compare the current and proposed behaviors for the following code: ```js <ScrollView automaticallyAdjustKeyboardInsets keyboardDismissMode="interactive"> {[...Array(10).keys()].map(item => ( <CustomTextInput placeholder={item.toString()} key={item} /> ))} </ScrollView> ``` | Current behaviour | Proposal | |-|-| |  |  | As can be seen in the video, the **current behavior** applies an offset to the `ScrollView` content regardless of where the `TextInput` sits on the screen. The proposal checks if the `TextInput` will be covered by the keyboard, and only then applies an offset. The offset applied is not the full size of the keyboard but instead only the required amount so that the `TextInput` is a **specific** distance above the top of the keyboard (customizable using the new `bottomKeyboardOffset` prop). This achieves a less "jumpy" experience for the user. The proposal doesn't change the behavior of the `ScrollView` offset when an `InputAccessory` view is used, since it checks if the `TextField` that triggered the keyboard is a **descendant** of the `ScrollView` or not. ## Why not use other existing solutions? RN ecosystem offers other alternatives for dealing with a keyboard inside a ScrollView, such as a `KeyboardAvoidingView` or using third party libraries like `react-native-keyboard-aware-scroll-view`. But as shown in the recordings below, these solutions don't provide the smoothness or behavior that can be achieved with `automaticallyAdjustsScrollIndicatorInsets`. | KeyboardAvoidingView | rn-keyboard-aware-scroll-view | |-|-| |  |  | As shown in the videos, the `TextInput` is hidden by the keyboard for a split second before becoming visible. Code for the videos above: ```js // KeyboardAvoidingView <KeyboardAvoidingView style={{flex: 1, flexDirection: 'column', justifyContent: 'center'}} behavior="padding" enabled> <ScrollView> {[...Array(10).keys()].map(item => ( <CustomTextInput placeholder={item.toString()} key={item} /> ))} </ScrollView> </KeyboardAvoidingView> ``` ```js // rn-keyboard-aware-scroll-view <KeyboardAwareScrollView> {[...Array(10).keys()].map(item => ( <CustomTextInput placeholder={item.toString()} key={item} /> ))} </KeyboardAwareScrollView> ``` Reviewed By: sammy-SC Differential Revision: D49269426 Pulled By: javache fbshipit-source-id: 6ec2e7b45f6854dd34b9dbb06ab77053b6419733
Summary: Pull Request resolved: facebook#39464 We currently have 854 warnings emitted due to nested namespaces being a C++ 17 extension lol. This sets the standard explicitly to C++ 20 in the specs emitting the warnings (mostly RCT-Text). It is undesirable that we add hundreds of warnings to the CocoaPods build without signal. Our Buck build and OSS Android build both treat warnings as errors. But... that is for another day. Changelog: [Intenrnal] Reviewed By: cortinico Differential Revision: D49303081 fbshipit-source-id: 1233e9d51426fb8dbd8ca39a771e2fef3d0df856
|
Hi @alwaysowner007! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
Base commit: 5ea0b44 |
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:
Changelog:
Test Plan: