Uh oh!
There was an error while loading. Please reload this page.
Merge up to September 20th - #1939
Merged
Merged
Conversation
Summary: Pull Request resolved: react#39219 X-link: react/yoga#1350 Pull Request resolved: react#39170 ## This diff This diff adds a top level `node` directory for code related to Yoga nodes and data structures on them (inc moving `YGLayout` to `LayoutResults`). The public API for config handles is `YGNodeRef`, which is forward declared to be a pointer to a struct named `YGNode`. The existing `YGNode` is split into `yoga::Node`, as the private C++ implementation, inheriting from `YGNode`, a marker type represented as an empty struct. The public API continues to accept `YGNodeRef`, which continues to be `YGNode *`, but it must be cast to its concrete internal representation at the API boundary before doing work on it. This change ends up needing to touch quite a bit, due to the amount of code that mixed and matched private and public APIs. Don't be scared though, because these changes are very mechanical, and Phabricator's line-count is 3x the actual amount due to mirrors and dirsyncs. ## This stack The organization of the C++ internals of Yoga are in need of attention. 1. Some of the C++ internals are namespaced, but others not. 2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these) 2. Most of the files are in a flat hierarchy, except for event tracing in its own folder 3. Some files and functions begin with YG, others don’t 4. Some functions are uppercase, others are not 5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about 6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h) 7. There is no clear indication from file structure or type naming what is private vs not 8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers This stack does some much needed spring cleaning: 1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy 3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended 4. Utils files are split 5. Most C++ internals drop the YG prefix 6. Most C++ internal function names are all lower camel case 7. We start to split up Yoga.cpp 8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings 9. It is not possible to use private APIs without static casting handles to internal classes This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well. These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer. Changelog: [Internal] bypass-github-export-checks Reviewed By: shwanton Differential Revision: D48847258 fbshipit-source-id: fc560893533b55a5c2d52c37d8e9a59f7369f174
Summary: Pull Request resolved: react#39220 X-link: react/yoga#1354 Pull Request resolved: react#39197 ## This diff Moves these files to a `yoga/debug` subdirectory and does some mild renaming, namespace adjustment, and removes Yoga internal log function from list of library exports. ## This stack The organization of the C++ internals of Yoga are in need of attention. 1. Some of the C++ internals are namespaced, but others not. 2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these) 2. Most of the files are in a flat hierarchy, except for event tracing in its own folder 3. Some files and functions begin with YG, others don’t 4. Some functions are uppercase, others are not 5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about 6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h) 7. There is no clear indication from file structure or type naming what is private vs not 8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers This stack does some much needed spring cleaning: 1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy 3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended 4. Utils files are split 5. Most C++ internals drop the YG prefix 6. Most C++ internal function names are all lower camel case 7. We start to split up Yoga.cpp 8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings 9. It is not possible to use private APIs without static casting handles to internal classes This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well. These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer. bypass-github-export-checks Reviewed By: shwanton Differential Revision: D48847259 fbshipit-source-id: c1607b1c6457d5a47039c735cdb7c365a301ebc0
Summary: Pull Request resolved: react#39222 X-link: react/yoga#1357 Pull Request resolved: react#39199 ## This diff This splits `Utils.h` and `Utils.cpp`, and tweaks naming and namespaces. ## This stack The organization of the C++ internals of Yoga are in need of attention. 1. Some of the C++ internals are namespaced, but others not. 2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these) 2. Most of the files are in a flat hierarchy, except for event tracing in its own folder 3. Some files and functions begin with YG, others don’t 4. Some functions are uppercase, others are not 5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about 6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h) 7. There is no clear indication from file structure or type naming what is private vs not 8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers This stack does some much needed spring cleaning: 1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy 3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended 4. Utils files are split 5. Most C++ internals drop the YG prefix 6. Most C++ internal function names are all lower camel case 7. We start to split up Yoga.cpp 8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings 9. It is not possible to use private APIs without static casting handles to internal classes This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well. These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer. bypass-github-export-checks Reviewed By: shwanton Differential Revision: D48847260 fbshipit-source-id: b99df3029cd66257a7ae64de28c13e8751ceb20c
Summary: Pull Request resolved: react#39224 X-link: react/yoga#1356 Pull Request resolved: react#39196 ## This diff This renames YGFloatOptional to FloatOptional, adds it to a namespace, and moves it to a subdirectory. This needs Fabric updates because Fabric uses Yoga internals for props storage. ## This stack The organization of the C++ internals of Yoga are in need of attention. 1. Some of the C++ internals are namespaced, but others not. 2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these) 2. Most of the files are in a flat hierarchy, except for event tracing in its own folder 3. Some files and functions begin with YG, others don’t 4. Some functions are uppercase, others are not 5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about 6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h) 7. There is no clear indication from file structure or type naming what is private vs not 8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers This stack does some much needed spring cleaning: 1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy 3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended 4. Utils files are split 5. Most C++ internals drop the YG prefix 6. Most C++ internal function names are all lower camel case 7. We start to split up Yoga.cpp 8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings 9. It is not possible to use private APIs without static casting handles to internal classes This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well. These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer. Changelog: [Internal] bypass-github-export-checks Reviewed By: shwanton Differential Revision: D48847256 fbshipit-source-id: ab9729a4a02ab90d974183425935f4d274db5732
Summary: Pull Request resolved: react#39223 Pull Request resolved: react#39200 X-link: react/yoga#1351 ## This diff This splits up `BitUtils.h`, does some minor renaming, and namespace consistency fixes. ## This stack The organization of the C++ internals of Yoga are in need of attention. 1. Some of the C++ internals are namespaced, but others not. 2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these) 2. Most of the files are in a flat hierarchy, except for event tracing in its own folder 3. Some files and functions begin with YG, others don’t 4. Some functions are uppercase, others are not 5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about 6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h) 7. There is no clear indication from file structure or type naming what is private vs not 8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers This stack does some much needed spring cleaning: 1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy 3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended 4. Utils files are split 5. Most C++ internals drop the YG prefix 6. Most C++ internal function names are all lower camel case 7. We start to split up Yoga.cpp 8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings 9. It is not possible to use private APIs without static casting handles to internal classes This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well. These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer. bypass-github-export-checks Reviewed By: shwanton Differential Revision: D48847255 fbshipit-source-id: 4b9722303372f43e936118f8187c0127bceeb1d4
…react#39234) Summary: In some occasion, we have a race condition when: - prepare hermes workspace has some artifacts but not all of them, and it store them to the workspace - the pipeline rebuilds the missing artifacts - the build_hermes_macos jobs tries to upload the pre-existing artifacts, uploading the whole folder. So, for example, imagine that at the prepare_hermes_workspace time, we are able to restore both the `hermes-ios-release.tar.gz` and the `hermes-ios-debug.tar.gz`. When the two concurrent `build_hermes_MacOS-Debug` and `build_hermes_MacOS-Release`, they will both try to upload both tars at the same time, and that results in the concurrent errors we are seeing. This change should fix this, by having the Debug job upload the Debug artifacts only and the Release jobs upload the Release artifacts only, so there will be no concurrent upload of the same files. ## Changelog: [Internal] - Upload Hermes macos artifacts depending on the Build flavor. Pull Request resolved: react#39234 Test Plan: CircleCI stays green. Reviewed By: GijsWeterings Differential Revision: D48861430 Pulled By: cipolleschi fbshipit-source-id: 02bd045cdb969ad1c173e78ffb42185c14ba171e
Summary: Pull Request resolved: react#39211 Some tests were not running because they were disabled when experiment with `enableCalculateTransformedFrames`. Instead, run tests against both variants of the experiment so differences can be better understood. Changelog: [Internal] Reviewed By: rshest Differential Revision: D48826739 fbshipit-source-id: 5d6fd12e7ab396e4c2f6ee602cdc0aa47b8f45f3
Summary: Pull Request resolved: react#39161 Changelog: [Internal] Creates a new stub package named `react-native/debugger-frontend`, which will contain a minimal build of the Chrome DevTools frontend adapted for React Native. Initially, the compiled frontend assets will be checked into the React Native repo, but we intend to replace this with a fully automated build in CI at a later date. Reviewed By: huntie Differential Revision: D48680624 fbshipit-source-id: a24c8b019881187963d0be88e773bc0a97a2437d
Summary: Pull Request resolved: react#39226 Changelog: [Internal] Syncs a custom build of the Chrome DevTools frontend (performed using the script in D48680624) into the `react-native/debugger-frontend` package. **The package is not used anywhere yet.** In a subsequent diff, it will be integrated into `react-native/dev-middleware`. Review the `BUILD_INFO` file for information about the source revision and build settings that were used to generate this diff. Reviewed By: huntie Differential Revision: D48682302 fbshipit-source-id: 50ea532f45d8c751c141d5f4253afe080af31559
Summary: Pull Request resolved: react#39238 This does nothing useful. Let's get rid of it. Changelog: [Internal] Reviewed By: philIip Differential Revision: D48833211 fbshipit-source-id: 0b6937f83148bb2ddc66212d2669e72887430364
Summary: Pull Request resolved: react#39244 Changelog: [Internal] TSIA. Fixup from D48680624. #publish-packages-to-npm bypass-github-export-checks Reviewed By: huntie Differential Revision: D48869800 fbshipit-source-id: 40733d09f9423232b4b5adb120bf268f8f7e4994
Summary: Pull Request resolved: react#39242 Reverts external behaviour of react#39122. - `/json/list` once again returns the built-in `devtools://devtools/bundled/js_app.html` URL — effectively freezing the current experience in Flipper. - `/open-debugger` continues to use the *new* frontend via `getDevToolsFrontendUrl`. - *Eventually*, we'll want to align this as the returned `devtoolsFrontendUrl` value once Flipper is out of the picture. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D48868767 fbshipit-source-id: 088ecebffa6ce45cb9bed44e3b02df4b7b471068
Summary: Pull Request resolved: react#39202 This diff adds `PerformanceStatsHistory.kt` which is used to track performance stat in buckets with resolution (in ms) and size. This is to help group perf stats in a time series data structure that we can adapt to any visualization in the future. Changelog: [Internal] - Performance monitoring overlay improvements Reviewed By: rshest Differential Revision: D48657874 fbshipit-source-id: 3e3fe7c50db6672b1eff117a36f0de72a774fc96
Summary: Pull Request resolved: react#39246 Appears to no longer be used Reviewed By: boxinYang Differential Revision: D48872901 fbshipit-source-id: 3fd376b30304a1dc643ef77ffa503376dbbab7e7
Summary: The motivation was to create more e2e tests that test other components in the RNTester app. The list of components that have been tested is below: | Component|Test is added|Platform| | :--- | :----: |---: | |DrawerLayoutAndroid|NO|Android| |ActivityIndicator|YES|iOS & Android| |Button|YES|iOS & Android| |FlatList|YES|iOS & Android| |Image|NO|iOS & Android| |JSResponderHandler|YES|iOS & Android| |InputAccessoryView|NO|iOS| |KeyboardAvoidingView|YES|iOS & Android| |Modal|YES|iOS & Android| |New App Screen|YES|iOS & Android| |Pressable|YES|iOS & Android| |RefreshControl|YES|iOS & Android| |ScrollView|NO|iOS & Android| |ScrollViewSimpleExample|YES|iOS & Android| |SafeAreaView|NO|iOS| |ScrollViewAnimated|NO|iOS & Android| |ScrollViewIndicatorInsets|NO|iOS| |SectionList|NO|iOS & Android| |StatusBar|NO|iOS & Android| |SwipeableCard|NO|iOS & Android| |Switch|NO|iOS & Android| |Text|NO|iOS & Android| |TextInput|NO|iOS & Android| |Touchable* and onPress|NO|iOS & Android| |TextInputs with key prop|NO|Android| |TransparentHitTestExample|NO|iOS| |View|NO|iOS & Android| |New Architecture Examples|NO|iOS & Android| |Performance Comparison Examples|NO|iOS & Android| ## Changelog: [General] [Added] - Added next component tests for RNTester Pull Request resolved: react#39117 Test Plan: Follow Readme file. ## Test Result: For iOS platform:<br>  For Android platform:<br>  Reviewed By: yungsters Differential Revision: D48828525 Pulled By: cipolleschi fbshipit-source-id: dfe7cc9871666a6b5c0704a207ca1eeb65f50114
Summary: Pull Request resolved: react#39251 As `react-native/babel-preset` is extended to include parts of codegen (written in Flow) via `react-native/babel-plugin-codegen`, we need to register Babel (with a Node JS config) in order to load the `react-native/babel-transformer` that Jest needs to transform RN code when running from source. (This is *only* relevant to running from source, ie internally at Meta or when developing on a clone of the OSS repo) Changelog: [Internal] Reviewed By: huntie Differential Revision: D48871440 fbshipit-source-id: 2f206b2380d67007e37782f211a6e831b35291f8
Summary: react#38963 introduced a regression that breaks downloading hermes tarball for nightlies. It fails with the following error when running `pod install`: ``` Fetching podspec for `hermes-engine` from `../../../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec` [!] Failed to load 'hermes-engine' podspec: [!] Invalid `hermes-engine.podspec` file: undefined local variable or method `react_native_path' for Pod:Module Did you mean? react_native_post_install. ``` The root cause is that the `download_nightly_hermes` method was just not implemented. ## Changelog: [IOS] [FIXED] - Fixed downloading hermes tarball for nightlies Pull Request resolved: react#39243 Test Plan: After applying these changes, `pod install` in my project no longer fails and downloads the tarball correctly. Reviewed By: dmytrorykun Differential Revision: D48897925 Pulled By: cipolleschi fbshipit-source-id: a504f01b739862bd092f22bca1f240f6df3a6df8
Summary: Seems to be invalid given the other jsi import Pull Request resolved: react#39247 Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D47380384 fbshipit-source-id: 226a3e213176e50b4c882b5ea3f10c57130bd494
Summary: Pull Request resolved: react#39248 `Bridgeless` -> `Runtime` in .podspec changelog: [internal] internal Reviewed By: fkgozali, cipolleschi Differential Revision: D48789176 fbshipit-source-id: bc656097e0274c7381e66117d91e7300d5c6f6c4
Summary: Pull Request resolved: react#39239 We can avoid static guards and heap allocation memory by forcing a default initialized shared_ptr (which is constexpr), and telling the compiler to not bother with registering a destructor, as these shared_ptr will never hold a value. Changelog: [Internal] Reviewed By: rshest Differential Revision: D48867013 fbshipit-source-id: c31f535bb19382878c9f21d7145188bd91b63265
Summary: This PR adds transform-origin support for iOS fabric. This PR also incorporates feedback/changes suggested by javache in the original [PR.](react#37606) ## Changelog: [IOS] [ADDED] - Fabric Transform origin <!-- 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 Pull Request resolved: react#38559 Test Plan: Run iOS RNTester app in old architecture and test transform-origin example in `TransformExample.js`. Reviewed By: NickGerleman Differential Revision: D48528363 Pulled By: javache fbshipit-source-id: 347b7c5896ad19ad24278de81b0e055e4cb01016
Summary: This PR adds transform-origin support for android to make it easier to review. react#37606 (review) by javache. I'll answer feedback from javache below. ## Changelog: [Android] [ADDED] - Transform origin <!-- 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 Pull Request resolved: react#38558 Test Plan: Run iOS RNTester app in old architecture and test transform-origin example in `TransformExample.js`. Reviewed By: NickGerleman Differential Revision: D48528339 Pulled By: javache fbshipit-source-id: e255a7f364e57396dada60b2c69c724cec406f51
Summary: Adds transform-origin for old arch iOS See also intergalacticspacehighway's work for iOS Fabric and Android:- - react#38559 - react#38558 ## Changelog: [IOS] [ADDED] - Added support for transform-origin on old arch Pull Request resolved: react#38626 Test Plan: See RN tester Reviewed By: NickGerleman Differential Revision: D48528353 Pulled By: javache fbshipit-source-id: 09592411e26484d81a999a7e601eff751ca7ae0b
…act#39225) Summary: Previously, when you tried to create some styles using `StyleSheet.create`, you can create styles with invalid styles: ```ts const styles = StyleSheet.create({ container: { marginLeft: 1, magrinRight: 1, // This is a typo, but would not cause typecheck errors }, }); ``` The root cause is that Typescript uses a looser [Excess Property Checks](https://www.typescriptlang.org/docs/handbook/2/objects.html#excess-property-checks) if we're using template types rather than using the actual specific types in the function signature. - DefinitelyTyped/DefinitelyTyped#62481 ## Changelog: [INTERNAL] [FIXED] - Make StyleSheet.create better check property keys for typos Pull Request resolved: react#39225 Test Plan: Added a test in __typeTests__, which should get run by CI. Reviewed By: rshest Differential Revision: D48859679 Pulled By: NickGerleman fbshipit-source-id: 43aa69cf85cd69353d053b782dba73ab2027eb64
Summary: Chronos Job Instance ID: 1125907940766435 Sandcastle Job Instance ID: 22517999172097970 allow-large-files ignore-conflict-markers opt-out-review Differential Revision: D48929200 fbshipit-source-id: 0a19658d278a4832a5defaba85c3f7c4f589167a
Summary: Pull Request resolved: react#39264 X-link: facebook/hermes#1113 Since C++20, the type of a `u8"..."` string literal is `const char8_t[N]` whereas prior to C++20 the type is `const char[N]`. `char8_t` has the same size, alignment, and signedness as `unsigned char` but is a different type from `unsigned char`, as well as being a different type from `signed char` and from `char`. In context, the uses of the `u8"..."` expect `const char*` (to which `const char[N]` decays) and not `const char8_t*` (to which `const char8_t[N]` decays). To fit the string to the context since C++20, we must `reinterpret_cast` to `const char*`; this is a type-level no-op prior to C++20. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D48908076 fbshipit-source-id: e68d8fc4ff9dfb9528846901e37e2775c2b98866
Summary: Chronos Job Instance ID: 1125907940832858 Sandcastle Job Instance ID: 13510799920053222 allow-large-files ignore-conflict-markers opt-out-review Differential Revision: D48941197 fbshipit-source-id: 41d203e41df61c743f2372fe84c3eb9756bb04ba
Summary: Pull Request resolved: react#39253 X-link: facebook/hermes#1112 Changelog: [Internal] Forks `ReactCommon/hermes/inspector` → `ReactCommon/hermes/inspector-modern`. More changes to `inspector-modern` will come in subsequent diffs. The Gradle, CocoaPods and Buck builds of React Native have been updated to use `inspector-modern` everywhere. The code in `ReactCommon/hermes/inspector` is thus **deprecated** and unused in the open source build, and will be deleted in an upcoming diff (likely before the 0.73 cut). NOTE: The reason we're not immediately deleting `ReactCommon/hermes/inspector` is that there are a handful of references to it in Meta's internal monorepo (*outside of React Native*) that we are in the process of migrating away. Once we've deleted the existing `ReactCommon/hermes/inspector`, we *may* rename `inspector-modern` back to `inspector`. Reviewed By: blakef Differential Revision: D48897203 fbshipit-source-id: 13682747d280a3231b7f6bce560f25ad174304e9
Summary:
I've seen that this throws a warning:
```
<ImageBackground source={{ uri: undefined }}>
```
But this is properly working, without a warning, thus, I believe the code is allowing it:
```
<ImageBackground source={isLoading ? undefined : { uri: 'https://....' }}>
```
## Changelog:
[GENERAL] [CHANGED] - Fixed `source` in `Image` type
Pull Request resolved: react#39230
Test Plan: Not necessary. It's just a DOC change
Reviewed By: rshest
Differential Revision: D48939824
Pulled By: NickGerleman
fbshipit-source-id: fca2e07b7b4d4b947e365bb9d82fcf4cea484951Summary: Converts ColorUtilTest to kotlin as requested in react#38825 ## Changelog: [INTERNAL] [CHANGED] - Convert ColorUtilTest to Kotlin Pull Request resolved: react#38979 Test Plan: 1. Run `./gradlew :packages:react-native:ReactAndroid:test`. 2. All tests should pass. Reviewed By: fkgozali, cortinico, arushikesarwani94 Differential Revision: D48802302 Pulled By: mdvacca fbshipit-source-id: 876caf288bd5df1e1fdc4b0b20b41afdfacf364f
Saad Najmi (Saadnajmi)force-pushed
the
tip
branch
from
September 30, 2023 01:20
dae6a62 to
f195dbfCompare4 tasks
Saad Najmi (Saadnajmi)force-pushed
the
tip
branch
4 times, most recently
from
October 2, 2023 11:34
1a8fea8 to
7adae4aCompare4 tasks
Saad Najmi (Saadnajmi)force-pushed
the
tip
branch
from
October 2, 2023 13:17
7adae4a to
2a6fc58CompareDanny van Velzen (dannyvv)
approved these changes
Oct 2, 2023
Saad Najmi (Saadnajmi)force-pushed
the
tip
branch
from
October 2, 2023 17:46
2a6fc58 to
ba359ffCompareAdam Gleitman (amgleitman)
approved these changes
Oct 2, 2023
Saad Najmi (Saadnajmi) added a commit
that referenced
this pull request
Oct 2, 2023
This reverts commit 47bf127.
This was referenced Oct 2, 2023
This file contains hidden or 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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
Please select one of the following
Summary
Merge upstream commits up to September 20th. That puts us very close to the 0.73 branch cut and also closes much of the gap between our two repositories. It's difficult to keep an a 100% accurate list of all the changes to the macOS implementation here (lots of moving ifdef macros around), but I'll try and provide a meaningful list, along with interesting upstream commits. I also took the opportunity to remove even more stale files / unnecessary diffs wherever I could.
Meaningful macOS changes (non-exhaustive):
launchPackager.commandas our CI depends on itRCT_NEW_ARCH_ENABLED=1react/react-native#39719)Interesting upstream commits:
RCTBridge+cxx.(h|mm)in order for this commit to compile. That was a RNM only file that seemed unused/redundant so probably safe.Follow ups
Changelog
[INTERNAL] [CHANGED] - Merge upstream commits up to September 20th
Test Plan
useWindowDimensionshook still functions properly after theRCTDeviceInforefactorsecureTextEntryTextInput example still works