Summary:
X-link: https://github.com/facebook/yoga/pull/1533
Pull Request resolved: https://github.com/facebook/react-native/pull/42031
I have some reservations about some of the conditional setting of trailing position in general, and some of the repeated transformations that neccesitates this, but these functions don't belong in `CalculateLayout.h`. For now, just move these to their own header.
Reviewed By: joevilches
Differential Revision: D52292121
fbshipit-source-id: 4a998a4390a8d045af45f5424adaf049ed635e7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41519
Changelog: [Internal] - Refactor hover tracking logic to the shared c++ renderer
This diff refactors our hover tracking logic out of the platform (in this case only iOS, integrating Android is going to require extra work due to their pointer events being untyped) and puts it into the event intercepting infra in Fabric's C++ core. This is a big-ish diff so I'm going to try my best to use this summary to guide you through the changes.
To begin with — the changes inside `RCTSurfacePointerHandler.mm` are mostly about removing the existing hover tracking logic. The logic of the hover tracking is largely the same between the objective-c and c++ implementations with minor tweaks in order to be a better citizen when it comes to storing node references. One small "addition" to this file is explicitly firing a `pointerleave` event from the iOS layer when we detect that the pointer has left the app entirely because the C++ would otherwise not know when the pointer leaves the app. We don't need to include a special case for `pointerenter` because we can derive that in C++ from the first `pointermove` event that gets sent once the pointer re-enters the app's root view.
Next I think it makes most sense to continue onto the `PointerEventsProcessor.h/mm` which is the central class we're working in. One small change is adding a flag to the `ActivePointer` struct (`shouldLeaveWhenReleased`) which we will set during `ActivePointer` registration — setting to false if the pointer in question exists in the (also) newly added `previousHoverTrackersPerPointer_` registry. This logic is primarily used for knowing later when the pointer is released and whether we should emit the synthetic leave/out event on release. If the pointer existed in `previousHoverTrackersPerPointer_` **before** the `ActivePointer` registration that implies that the pointer is capable of hovering to some degree and we should **not** emit those leave/out events yet.
The real meat & potatoes of this diff is the `handleIncomingPointerEventOnNode` method which matches the `handleIncomingPointerEvent` method we removed from `RCTSurfacePointerHandler.mm`. This method derives the enter/leave/over/out pointer events by comparing the current event's target path (list of nodes from the root node to the target node of the event) to the previously recorded event target path. The representation of this event path is through the new `PointerHoverTracker` class which stores a pointer to just the root node and the target node as we can recreate the entire event path from these.
For over/out events all that matters is when the deepest-most target changes which is checked in `handleIncomingPointerEventOnNode` by leveraging `PointerHoverTracker`'s `hasSameTarget` method. For enter/leave events we need to fire discrete events for every node in the path which has either been removed or added, so the `diffEventPath` method was introduced on `PointerHoverTracker` to provide that.
Reviewed By: yungsters
Differential Revision: D51317492
fbshipit-source-id: e15ac3a396d5afa7ab921e4589861b43b07a33b5
Summary:
We have 1 coordinator per class but 1 adapter per instance.
Currently, the `oldProps` are stored in the coordinator and not into the adapter.
Therefore, when we create multiple instances of the same legacy component, the props might get messy or not updated properly.
This change moves the `oldProps` and the diffing code to the Adapter rather than to the coordinator, making them instance-specific.
## Changelog:
[iOS][Fixed] - Move old props and prop diffing to the interop layer adapter
Reviewed By: sammy-SC
Differential Revision: D52368222
fbshipit-source-id: 0f0c47b586fe61404250c5bfe51a7e2c63012815
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41925
This diff introduces the `npx react-native codegen` command.
It runs the codegen for the `package.json` file in current working directory.
Changelog: [General][Added] - Introduce "npx react-native codegen" command.
Reviewed By: cipolleschi
Differential Revision: D51495465
fbshipit-source-id: 1fd4c3645235a12f68f9032349a443b92b4764b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42012
Up until now `generate-codegen-artifacts.js` has been iOS only. But its logic is actually quite general, and this diff makes it platform agnostic.
Changelog: [General][Added] - Introduce the "platform" option to generate-codegen-artifacts.js
Reviewed By: RSNara
Differential Revision: D52257542
fbshipit-source-id: b7e698c779f7c6dae9b0de98a19ba452111fea5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42016
changelog: [internal]
TouchableWithoutFeedback is broken with React 18. Before we fix it, let's use Pressable in tests.
Reviewed By: fkgozali
Differential Revision: D52328529
fbshipit-source-id: 1d7d5032ffaf7f8ff5ffa47af2a87b733fd2e840
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42035
In upcoming diffs we will begin integrating the new C++ `InspectorPackagerConnection` (D52134592) into React Native on Android and iOS. This diff adds a shared C++ flag that is the source of truth for whether the new implementation should be enabled.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52335446
fbshipit-source-id: 7f16ffc1728c8de7d4fbf090268ffed6fbaa879f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42026
Previously, the examples allow overriding the testIDs for each inner example from ViewExample.js in RNTester. However, that setup relies on another infra/abstraction to inject the testIDs properly. For simplicity, let's just make them hardcoded using the pattern view-test-<example-name>.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52349100
fbshipit-source-id: 09d51935318d0592a9aae7da61cab0c87ac69152
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41987
Previously, the examples allow overriding the testIDs for each inner example from BorderExample.js in RNTester. However, that setup relies on another infra/abstraction to inject the testIDs properly. For simplicity, let's just make them hardcoded using the pattern `border-test-<example-name>`.
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D52282922
fbshipit-source-id: 8fdc3d799befddbbb9bd8e60c8a904670c035d59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41981
Improved RNTester URL deeplink support to cover:
* `rntester://example/<moduleKey>`
* `rntester://example/<moduleKey>/<exampleKey>`
Extra details:
* For example modules that do not specify `showIndividualExamples: true`, allow deeplink URL with the specific exampleKey to only render the specific example, instead of all of them.
* Added flexibility for moduleKey: search for optional suffixes ("Index", "Example").
* Adjusted Back button action to properly go back to the root after a deeplink.
* Added `example-container` generic testID on the example wrapper component.
Changelog: [Internal]
Reviewed By: yungsters, NickGerleman
Differential Revision: D52227013
fbshipit-source-id: 4ba050592f39d6895f5124fa25c77f2d0199aa3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42019
Removes the following deprecated properties from React Native:
- `Image.propTypes`
- `Text.propTypes`
- `TextInput.propTypes`
- `ColorPropType`
- `EdgeInsetsPropType`
- `PointPropType`
- `ViewPropTypes`
The deprecation history for these prop types is not super obvious, so here is a summary:
- `react@15.5` extracted `prop-types` into a separate package to reflect that not everybody uses them.
- `react-native@0.68` added a deprecation warning to built-in prop types. (https://github.com/facebook/react-native/commit/3f629049ba9773793978cf9093c7a71af15e3e8d)
- `react-native@0.69` removed built-in prop types. (https://github.com/facebook/react-native/commit/3e229f27bc9c7556876ff776abf70147289d544b)
- `react-native@0.71` restored built-in prop types, along with bug fixes to isolate deprecated usage. (https://github.com/facebook/react-native/commit/b966d297245a4c1e2c744cfe571396cfa7e5ffd3)
We believe that by the next public release, enough time will have passed for the community to be able to upgrade without patching React Native or otherwise working around the removal of these deprecated prop types.
**If anyone has trouble identifying the source of a deleted prop types usage, please file an issue so we can help track it down with you.**
Changelog:
[General][Removed] - Removed deprecated prop types
Reviewed By: lunaleaps, NickGerleman
Differential Revision: D52337762
fbshipit-source-id: 9731f7e1dec29f3df535ab75cc50bed001fdfa0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42017
Changelog: [Internal]
C++ unit tests for D52134592. The tests heavily use gtest / gmock features to mock the various interfaces associated with `InspectorPackagerConnection` (see `InspectorMocks.h`) and to make it easy to write complex assertions on dynamic and JSON values (see `FollyDynamicMatchers.h`).
To simplify access to the mock objects while they are owned by the `InspectorPackagerConnection` under test, I've also created the `UniquePtrFactory` helper (see doc comments and unit tests that fully explain its functionality).
Reviewed By: huntie
Differential Revision: D52134593
fbshipit-source-id: 23b8098232898be7e5cbd9b31b3358640c5e5eec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41977
Changelog: [Internal]
Adds a new C++ implementation of `InspectorPackagerConnection`, intended to eventually replace `RCTInspectorPackagerConnection` on iOS and `InspectorPackagerConnection.java` on Android.
The main *new* abstraction in the C++ version is the `InspectorPackagerConnectionDelegate` interface, which will allow each platform to plug in its own scheduler and WebSocket implementation
This is almost entirely a direct translation of the Objective-C implementation to C++, so I've modelled it as a file copy in source control for ease of review. We may iterate further on the API at a later date, especially once the old implementations are gone.
Reviewed By: huntie
Differential Revision: D52134592
fbshipit-source-id: b4778b9c4fd424c4fa8d23bb9171629874e50e73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41975
The version of `inspector-proxy` included with React Native has not used the `isLastBundleDownloadSuccess` and `bundleUpdateTimestamp` properties in years. This diff removes the backend support for reporting them (in preparation for a C++ rewrite of this infrastructure). We can consider bringing a similar feature back in the future on top of the modern CDP infra (which we are currently building).
Changelog: [General][Breaking] Remove APIs for reporting bundle download status to inspector-proxy, which does not use this information.
Reviewed By: huntie
Differential Revision: D52258567
fbshipit-source-id: e810278f949d8ab7dbc660cdc036a0f8464727f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41956
By default, generated Cxx sources for components all end up in same directory. However the include declarations in them look like this:
```
#include <react/renderer/components/${libraryName}/ShadowNodes.h>
```
And not like this:
```
#include "ShadowNodes.h"
```
This works fine with Buck because it supports header prefixes.
To get this working with CocoaPods we define additional `HEADER_SEARCH_PATHS` for our `React-Codegen` pod.
This approach will not work if we want to generate code at the library level and check in the artifacts. That's because we don't have control over the Podspec there, and can't inject those additional `HEADER_SEARCH_PATHS`.
This diff adds the `headerPrefix` argument to the codegen entry point. It is `react/renderer/components/${libraryName}` by default, but can become empty if we want to generate code at the library level, and don't want to deal with this nested header structure.
*Note:* `RNCodegen` runs all the generators [in a loop](https://github.com/facebook/react-native/blob/main/packages/react-native-codegen/src/generators/RNCodegen.js#L263-L275), assuming that the all have same function signature So I had to add the `headerPrefix` argument to all the generators, even to the ones that don't really need it.
Changelog: [General][Added] - Introduce "headerPrefix" codegen option.
Reviewed By: zeyap
Differential Revision: D51811596
fbshipit-source-id: c5c3e1e571c7c4ea2f5354eb9a7b0df6b917fc0c
Summary:
Adds changelog for the 0.72.8 release.
## 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
-->
[INTERNAL] [CHANGED] - Add changelog for the 0.72.8 release.
Pull Request resolved: https://github.com/facebook/react-native/pull/42011
Test Plan: Read the changelog 🤞
Reviewed By: christophpurrer
Differential Revision: D52325318
Pulled By: huntie
fbshipit-source-id: 377a81f255c909b7da9370d6e3856265e2081b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41974
Changelog: [Internal]
Switches `RCTInspectorPackagerConnection` to use the recommended and type-safe `didReceiveMessageWithString` method to receive messages from SRWebSocket.
Reviewed By: huntie
Differential Revision: D52257082
fbshipit-source-id: ce1233a06b15a353500f81ae5a7730422c668be7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41971
Original commit changeset: 29e1aba9c4ea
Original Phabricator Diff: D49956535
D49956535 added the new behaviour of logging helpful messages to the CDP console when the app is backgrounded/foregrounded. The underlying UX issue is legitimate: how do we reinforce the mental connection between the debugger frontend and the app being debugged, when they might be running in different windows or even machines, and particularly when the app might be backgrounded while the debugger frontend remains active.
However, this implementation is too closely coupled to the socket management layer, and is iOS-specific to boot. I'm removing it here to simplify porting `RCTInspectorPackagerConnection` to C++. We can revisit this UX problem later - preferably by investigating how it's handled in the case of Chrome Android and a remote DevTools client.
This feature has not been included in an OSS release of React Native yet, so very few users will be affected by its removal.
Changelog: [iOS][Removed] - Revert D49956535; remove console.log notification in DevTools if app transitions between back/foreground.
Reviewed By: blakef
Differential Revision: D51468311
fbshipit-source-id: b875d6cf03d3521c8e876c358b2299f20d395400
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41984
Changelog: [Internal]
this is unused anywhere, delete. for some reason we only have the spec file in oss but no native implementation
Reviewed By: christophpurrer
Differential Revision: D51968870
fbshipit-source-id: a4931d08c50954bfa557451e5e4d79a10dfeaefe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41976
Progress towards an opt-in setup for our new CDP backend.
- Wires up D51563107 to conditionally disable the legacy Hermes debugger via `ReactNativeConfig`.
- **Configuration covered**: iOS, for the `RCTAppDelegate` code path.
- Create C++-only overload of `RCTAppSetupPrepareApp`, deprecate the previous function.
Changelog:
[iOS][Deprecated] - Deprecate `RCTAppSetupPrepareApp`, replaced with C++ overload
Reviewed By: motiz88
Differential Revision: D51589221
fbshipit-source-id: 1688f97c69abb06d271b4d26b875365a8d86ba77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42002
Adds an E2E test on top of the RNTester example for this (as a practice we should probably do this for new examples).
I didn't add unit tests for this originally, but probably should do that as well if it gets more interesting...
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51639134
fbshipit-source-id: 379d95dfc676252e10b7076e294ac5534c6f06bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41994
X-link: https://github.com/facebook/yoga/pull/1529
Reorganizes the header according to common C++ convnetions. Public first, then private. Constructors, then functions, then member variables.
Reviewed By: joevilches
Differential Revision: D52106056
fbshipit-source-id: 0095cf7caa58dc79c1803b3b231911e4fc66ddaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41995
X-link: https://github.com/facebook/yoga/pull/1526
This function has made quite the journey from something that originally made more sense. This renames, refactors, and adds documentation for what it actually does.
This should eventually make its way into `yoga::Style` once computed style is moved into that structure.
bypass-github-export-checks
Reviewed By: joevilches
Differential Revision: D52105718
fbshipit-source-id: 6492224dd2e10cef3c5fc6a139323ad189a0925c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41939
X-link: https://github.com/facebook/yoga/pull/1520
This code originates as `YGValueResolve`, used to compute a YGValue to a length in points, using a reference for 100%.
This moves it to `Style::Length`, so we can encapsulate parts of it (for style value functions), and make the API more cohesive now that we can do C++ style OOP with it.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51796973
fbshipit-source-id: a7c359c7544f4bd2066a80d976dde67a0d16f1dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41776
X-link: https://github.com/facebook/yoga/pull/1492
# Summary
In preparation to replace `CompactValue`, this fully encapsulates it as an implementation detail of `yoga::Style`.
The internal API now always operates on `Style::Length`, converted to `YGValue` at the public API boundary.
In the next step, we can plug in a new representation within `Style`, which should enable 64 bit values, and lower memory usage.
# Test Plan
1. Existing tests (inc for style, invalidation, CompactValue) pass
2. Check that constexpr `yoga::isinf()` produces same assembly under Clang as `std::isinf()`
3. Fabric Android builds
4. Yoga benchmark does style reads
# Performance
Checking whether a style is defined, then reading after, is a hot path, and we are doubling any space style lengths take in the stack (but not long-term on the node). After a naive move, on one system, the Yoga benchmark creating, laying out, and destroying a tree, ran about 8-10% slower in the "Huge nested flex" example. We are converting in many more cases instead of doing undefined check, but operating on accessed style values no longer needs to do the conversion multiple times.
I changed the `CompactValue` conversion to YGValue/StyleLength path to check for undefined as the common case (since we always convert, instead of calling `isUndefined` directly on CompactValue. That seemed to get the difference down to ~5-6% when I was playing with it then. We can optimistically make some of this up with ValuePool giving better locality, and fix this more holistically if we reduce edge and value resolution.
On another machine where I tested this, the new revision went the opposite direction, and was about 5% faster, so this isn't really a cut and dry regression, but we see different characteristics than before.
# Changelog
[Internal]
Reviewed By: rozele
Differential Revision: D51775346
fbshipit-source-id: c618af41b4882b4a227c917fcad07375806faf78
Summary:
This PR optimises RCTKeyWindow() calls in `RCTForceTouchAvailable` method. This method was calling RCTKeyWindow hundreds of times while scrolling on the screen.
Before:
On the video you can see that this function is being called **350 times** just from simple list scrolling. RCTKeyWindow is looping over app windows so it's not a cheap operation.
https://github.com/facebook/react-native/assets/52801365/5b69cbd6-d148-4d06-b672-bd7b60472c13
After: the function is called only few times at the start of the app to get initial layout measurements.
Solution: I think we can check just once for the force touch capabilities as devices can't change it on the fly
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Optimise RCTKeyWindow() calls in RCTForceTouchAvailable method
Pull Request resolved: https://github.com/facebook/react-native/pull/41935
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D52172510
Pulled By: cipolleschi
fbshipit-source-id: 881a3125a2af4376ce65d785d8eee09c7d8f1f16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41655
This diff adds support for checked-in codegen artifacts for libraries.
It introduces a new property to `codegenConfig`, called `includesGeneratedCode`. If codegen sees `includesGeneratedCode: true` in a project's dependency, it assumes that the library has codegen artifacts in it, and will not generate any code.
Changelog: [General][Added] - Introduce "codegenConfig.includesGeneratedCode" property.
Reviewed By: cipolleschi
Differential Revision: D51207265
fbshipit-source-id: 65855fd846e24a53cb18008839121e99eeb59309
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41924
`utils.parseArgs` are only available in Node >=18.3, we can't use this function because we target Node >=18.0.
This diff replaces `utils.parseArgs` with `yargs`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52117818
fbshipit-source-id: 79223997874b6cfdea2ce38243b615a0dbb704a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41982
Moving the check for Fabric i.e. `ReactFeatureFlags.enableFabricRenderer` to old JSI Module path logic instead of new UIManagerProvider path for Fabric initialization and changing the default of UIManagerProvider from `null` -> `reactApplicationContext -> null;` since we are adding null check on the returned `UIManager`
Slight change of design of API for JSI Module in order to address the issues faced due to `ReactFeatureFlags.enableFabricRenderer`,
1. Getting rid of this check for the new Fabric initialization and keeping the old JSI Module path intact.
2. Allowing the UIManager to be nullable so as to allow Twilight surface not have UIManager set even though they it succeeds in initializing the TwilightJSIModule.
3. As made the UIManager nullable, added the null check for the same.
4. This eradicates the dependency on this flag for Anna as well.
Reviewed By: christophpurrer
Differential Revision: D52273097
fbshipit-source-id: bdf8b1de3771250c987c8f8bd4e48192f67a1afa
Summary:
Passed `--mode HermesDebug` to `run-android` command when running from watch mode by pressing `a` on terminal running a dev server. The flag is the same as in the `package.json`:
https://github.com/facebook/react-native/blob/27f38f6f0647ec1809ee0a0d8e9da3a77a9115b1/packages/rn-tester/package.json#L17
## Changelog:
[INTERNAL] [CHANGED] - Add missing params when running Android app from watch mode by pressing `a`
Pull Request resolved: https://github.com/facebook/react-native/pull/41979
Test Plan: Run `yarn start` press `a` in the watch mode, and Android app should be build and launch correctly.
Reviewed By: cipolleschi
Differential Revision: D52265462
Pulled By: lunaleaps
fbshipit-source-id: b2fbe6c889d8067876e160a8ce64dedcc4ce24d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41656
This change makes all the legacy components to go through the interop layer.
It also introduce the `RCTFabricInteropLayerEnabled()` and the `RCTEnableFabricInteropLayer(BOOL)` functions to work as feature flags behind the change to completely disable the Interop layer.
## Changelog
[iOS][Changed] - Make the Fabric Interop Layer automatic when the Nw architecture is enabled.
Reviewed By: cortinico
Differential Revision: D51586461
fbshipit-source-id: 8f92a76e6dbbee93055a1ebe49779dd64e484d95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41972
This diff adds the `DoubleConversion` dependency to the `install_modules_dependencies` function, that installs all the dependencies that third-party libraries might need.
The libraries will need the `DoubleConversion` pod if they include the generated Fabric files.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51848314
fbshipit-source-id: ae2ce022c6f51ce392852494c61e26ff810d30d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41936
This argument was removed in D51303793. This diff removes all remaining usages of it.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52035346
fbshipit-source-id: 99886be7ed810f58d8fb31fb22a44b2471e974ce
Summary:
Adds changelog for the 0.73.1 patch.
## 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
-->
[Internal] [Changed] - Add 0.73.1 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/41970
Reviewed By: christophpurrer
Differential Revision: D52253474
Pulled By: huntie
fbshipit-source-id: 18fb45afcbb4fa0f864916922c0e9d69cc6d213f
Summary:
I believe it's valuable to be able to initialise the React Native template into a mono-repo and have it work with zero updates to the configuration.
In its current form the template's Xcode project makes assumptions on the relative location of the `react-native` package, while it could instead use the `REACT_NATIVE_PATH` variable set in the `scripts/cocoapods/utils.rb` script:
https://github.com/facebook/react-native/blob/2441fa284716ef782ec12dd0c2801548f8c47339/packages/react-native/scripts/cocoapods/utils.rb#L82
via
https://github.com/facebook/react-native/blob/2441fa284716ef782ec12dd0c2801548f8c47339/packages/react-native/template/ios/Podfile#L35
## Changelog:
[IOS] [ADDED] - Add use of the `REACT_NATIVE_PATH` in the "Bundle React Native code and images" shell script build phase. This will help apps initialized into a mono-repo which hoists the `react-native` package.
Pull Request resolved: https://github.com/facebook/react-native/pull/41968
Test Plan: I initialized the React Native template into an NPM workspaces mono-repo and experienced a failure running the script phase. I updated it to the code in this PR, which resolved the issue.
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D52240559
Pulled By: robhogan
fbshipit-source-id: 1c5710c8ffe9d289f32c5ed83cb58ae27f3c931a
Summary:
X-link: https://github.com/facebook/yoga/pull/1525
Accidentally left this inconsistent with some of the refactoring. Rename the lone usage of `Length` within Style class to `Style::Length` to match the rest of the code.
This is functionally identical as before.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: yungsters
Differential Revision: D52096820
fbshipit-source-id: d6c569a02fb27a6e7548a9c12ff764afb823a282
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41964
X-link: https://github.com/facebook/yoga/pull/1524
D52087013 (#1513) fixed some issues, including where measuring under max-content or fit-content, align-content stretch would consume the entire available cross-dimensions, instead of only sizing to definite dimension, like the spec dicates.
I missed a case, where flexbox considers a container as having a definite cross-size if it is being stretched, even if it doesn't have a definite length.
https://www.w3.org/TR/css-flexbox-1/#definite-sizes
> 3. Once the cross size of a flex line has been determined, items in auto-sized flex containers are also considered definite for the purpose of layout;
> 1. If a single-line flex container has a definite cross size, the outer cross size of any stretched flex items is the flex container’s inner cross size (clamped to the flex item’s min and max cross size) and is considered definite.
We handle `align-items: stretch` of a flex container after cross-size determination by laying out the child under stretch-fit (previously YGMeasureModeExactly) constraint. This checks that case, and sizing the line container to specified cross-dim if we are told to stretch to it.
We could probably afford to merge this a bit with later with what is currently step 9, where we end up redoing some of this same math.
Reviewed By: yungsters
Differential Revision: D52234980
fbshipit-source-id: 475773a352fd01f63a4b21e93a55519726dc0da7
Summary: I've noticed that Bridge and Bridgeless initialize the list of ReactPackages using a different order, we are fixing it in this diff
Reviewed By: philIip
Differential Revision: D52145148
fbshipit-source-id: 6ad85bd0903f9beab455783e8deaf5c529b87a2e
Kevin Gozali
Vincent Riemer
David Vacca
Nick Gerleman
Riccardo Cipolleschi
Dmitry Rykun
Luna Wei
Samuel Susla
Alex Hunt
Moti Zilberman
Panos Vekris
Tim Yung
fortmarek
Alex Taylor (alta)
Phillip Pan
Pieter Vanderwerff
Oskar Kwaśniewski
Arushi Kesarwani
szymonrybczak
Thibault Malbranche
Kræn Hansen
Cheng Zhao