Summary:
This PR adds React native binding for https://github.com/facebook/yoga/pull/1116
## Changelog
[General] [Added] - Flex gap yoga bindings
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/34974
Test Plan:
Run rn tester app and go to view example. You'll find a flex gap example. Example location - `packages/rn-tester/js/examples/View/ViewExample.js`
### Tested on
- [x] iOS Fabric
- [x] iOS non-fabric
- [x] Android Fabric
- [x] Android non-fabric
To test on non-fabric Android, I just switched these booleans. Let me know if there's anything else I might have missed.
<img width="674" alt="Screenshot 2022-10-14 at 3 30 48 AM" src="https://user-images.githubusercontent.com/23293248/195718971-7aee4e7e-dbf0-4452-9d47-7925919c61dc.png">
Reviewed By: mdvacca
Differential Revision: D40527474
Pulled By: NickGerleman
fbshipit-source-id: 81c2c97c76f58fad3bb40fb378aaf8b6ebd30d63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35038
React-jsi provides JSI to allow React Native to interface with JavaScriptCore.
The hermes-engine Pod provides a second copy of JSI, as Hermes is built and linked statically with JSI.
This second copy of JSI would lead to an [ODR Violation](https://en.cppreference.com/w/cpp/language/definition).
To resolve this, when Hermes is enabled:
- React-hermes and hermes-engine are installed.
- React-jsc is not installed.
- React-jsi continues to be installed.
- React-jsi will not build JSI.
- React-jsi will declare a dependency on hermes-engine.
The result is that the JSI dependency for React Native is satisfied by hermes-engine, and there is no duplicate JSI library in the project.
When Hermes is disabled:
- React-jsi and React-jsc are installed.
- React-hermes and hermes-engine are not installed.
- React-jsi will build JSI.
Changelog:
[iOS][Changed] Resolve JSI ODR violation, make hermes-engine the JSI provider when Hermes is enabled
Reviewed By: cipolleschi
Differential Revision: D40334913
fbshipit-source-id: 409407a193a35cbd21b0e8778537b3627e4c54a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35031
The React-jsi Pod was serving two purposes: building JSI, and configuring JavaScriptCore as the JS engine.
By splitting the React-jsi Pod into React-jsi and React-jsi, we can start working towards de-coupling the JSI dependency from any particular JS engine.
Pods that depended on React-jsi, now depend on React-jsi and React-jsc.
One exception to this is React-hermes, which is only installed when Hermes is enabled, and thus does not require JavaScriptCore.
Upcoming commits should take care of removing the React-jsc dependency when Hermes is enabled, but it is out of scope for this commit.
Changelog:
[iOS][Changed] - The JSC Runtime is now provided by the React-jsc Pod instead of React-jsi. Libraries that declared a dependency on React-jsi in order to specifically create a JSC runtime (`makeJSCRuntime()`) will need to add React-jsc to their dependencies.
Reviewed By: dmytrorykun
Differential Revision: D40442603
fbshipit-source-id: b9b21146b9deb401f80cfef76a87c9867754a953
Summary:
Changelog:
[Internal][ErrorHandling] 3/n Add a gate for parsing unhandled JS errors in C++
Gate this just in case it causes issues. Enabling this is definitely a better behavior than before, because we want the JS stack when there is a JS error, not the native stack.
Reviewed By: sammy-SC
Differential Revision: D40397393
fbshipit-source-id: 586b4d7bcf710edb048b5c643646ba2f3c4c302a
Summary:
iOS did not support the implementation of Korean word-wrap(line-break) before iOS14.
If the attribute applied, the word-wrap of Korean will works.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Added] - Line break strategy for Text and TextInput components
Pull Request resolved: https://github.com/facebook/react-native/pull/31272
Test Plan:
1. Test build and run on above iOS 14.
2. Test it does not affect existing text components when set default(none) strategy.
3. Test whether word-wrap works with Korean when set hangul-word strategy.
<img src="https://user-images.githubusercontent.com/26326015/112963967-d7f70c00-9182-11eb-9a34-8c758b80c219.png" width="300" height="" style="max-width:100%;">
Reviewed By: javache
Differential Revision: D39824809
Pulled By: lunaleaps
fbshipit-source-id: 42cb0385221a38c84e80d3494d1bfc1934ecf32b
Summary: Currently, link groups depend on supermodules to generate. To continue supporting link groups while allowing us to migrate off supermodules, we'll add a talkios_link_group label on all talkios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D40268252
fbshipit-source-id: 9211add120448e95f892d36a85583c700b2ec9a0
Summary:
Changelog: [iOS][Internal] - Get the "move across" pointer event test passing on iOS
After implementing the "MoveAcross" pointer event test it indicated that the implementation, at least on iOS, was firing the events in an incorrect order. Extrapolating from the test's expectations all the events related to entering/leaving/ect. should fire before the down/move/up instead of placing those down/move/up/ect. between the leave and enter events.
Reviewed By: lunaleaps
Differential Revision: D39221372
fbshipit-source-id: 31b7292e524a9ec9d998e658b7d0ef3ebc825d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34869
Changelog: [Internal]
This merges all instances of `enablePropIteratorSetter` into a single one.
Both `AccesibilityProps` and `BaseTextProps` had their own instances if it, which is now redundant.
Reviewed By: cipolleschi
Differential Revision: D40062555
fbshipit-source-id: b6ccf5a9538612dd731a6f9c4eaceeebcb6d95be
Summary:
While working on https://github.com/facebook/react-native/pull/34513 I noticed that on main branch the versioning is not really consistent everywhere. So this PR is an attempt at realigning so that on the main branch, RN is 1000.0.0 everywhere - in a way, it's cleaning up the room for the monorepo work to go flawlessly).
It's just a pass of `node scripts/set-rn-version.js --to-version 1000.0.0`.
There's the small chance that some versions where kept to 0.0.0 on purpose (build tools are weird), so we might just have to close this off. No big deal :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - re-align version to be 1000.0.0 on main everywhere
Pull Request resolved: https://github.com/facebook/react-native/pull/34817
Test Plan: CI is green and when imported, nothing breaks.
Reviewed By: cortinico
Differential Revision: D39926953
Pulled By: cortinico
fbshipit-source-id: ff66530382f891e17c00b35edf97c03591b6a9a8
Summary:
A follow up to D38708718 (https://github.com/facebook/react-native/commit/403fea25f65a38f4b4d8e0edcf89741b29e62059) review, this factors feature flags for Fabric core code into a separate file, `CoreFeatures`.
Keeping them together is arguably better for maintenance and makes code easier to reason about.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D40007784
fbshipit-source-id: 1885d5d6200575c6015f063d8b05813b18b47ffb
Summary:
Found and removed duplicates of the word "the" in comments.
## Changelog
[Internal] [Removed] – Removed duplicates of the word "the" in comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/34807
Test Plan: Not applicable.
Reviewed By: yungsters, cipolleschi
Differential Revision: D39880587
fbshipit-source-id: b7277aa70604902929903c31ab69d4c532f2667a
Summary:
Brings in line with rest of code base and avoids running into this error
```
‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
```
when `Requires Only App-Extension-Safe-API` is set to Yes.
## Changelog
[iOS] [Fixed] - Update usage of UIApplication.sharedApplication in RCTKeyCommands
Pull Request resolved: https://github.com/facebook/react-native/pull/34787
Test Plan: Setting `Requires Only App-Extension-Safe-API` to Yes before this change means the app will not compile, after the change it does.
Reviewed By: dmytrorykun
Differential Revision: D39812410
Pulled By: cipolleschi
fbshipit-source-id: 78d185ba20301b10609e4a387f000f0cfda55663
Summary:
Changelog: [Internal][Bridgeless][iOS]
# Before diff
Be in Venice > run Metro > run FBiOS > navigate to any RN surface.
`UIManagerBinding createAndInstallIfNeeded` happens After `ReactInstance loadScript -> evaluateJavaScript`: install Fabric UIManager before main bundle execution
Reviewed By: RSNara
Differential Revision: D39760231
fbshipit-source-id: f17bf02e9b1fb0f9b0ff24c86aa6dc9349c42192
Summary:
We want to fix the order of execution of layout, layout effects and passive effects in React Native, but the use of the Fabric background executor for layout complicates this (and other things).
This brings back a flag to disable this background thread to do layout synchronously in JavaScript, before the execution of layout effects and passive effects.
This is expected to regress performance on some screens, so we need to address the antipatterns in those screens before shipping this.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39727131
fbshipit-source-id: 4323b089234d3304ca3bfe5697668fb44ac64c12
Summary:
Currently, fbios link groups depend on supermodules to generate. To continue supporting
link groups while allowing us to migrate off supermodules, we'll add a `fbios_link_group` label on all fbios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D39543862
fbshipit-source-id: 2abe5b3ee883e77336076d88436a1c84139b5a97
Summary:
This behaviour diverges from the original SafeAreaView implementation and causes issues when you try to use SafeAreaView in non-root placements (not recommended)
Changelog: [iOS][Internal]
Reviewed By: sammy-SC
Differential Revision: D39497303
fbshipit-source-id: 03bc288557f611bd4a8c16b3a6df8887e89ee9ec
Summary:
Adding support for application to hook into further tracing methods
## Changelog
[General][Added] - Add additional Systrace support
Reviewed By: NickGerleman
Differential Revision: D38673212
fbshipit-source-id: 55a90a0cd57809bca5f01da7acddcf253e5852ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34514
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 3/n - Move RCTTurboModuleRegistry.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirety of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
Reviewed By: RSNara
Differential Revision: D38971168
fbshipit-source-id: 3b1b23d422f965a5a14bc4178d32b844906f2c8b
Summary:
changelog: [internal]
preemtive view allocation has been disabled on iOS for over a year. We kept the code in but didn't do anything with it. This diff removes the code and related mobile config.
Post where we decided to turn preemtive view allocation off: https://fb.workplace.com/groups/215742978987717/permalink/832644567297552/
jest_e2e[run_all_tests]
Reviewed By: mdvacca
Differential Revision: D37922589
fbshipit-source-id: 1af8949cbbd9d48a2d80ca238b280178cbe2ead5
Summary:
Changelog: [Internal] Move Bridge-only constants into a separate file
- Move Bridge only constants from RCTBridge.h into RCTBridgeConstants.h.
- Move shared constants from RCTBridge.h into RCTConstants.h.
This way, new architecture does not need to import RCTBridge.h just for the constants.
Reviewed By: sammy-SC
Differential Revision: D39085713
fbshipit-source-id: 40177cbed72a326b40ec448c98751d1dd3464504
Summary:
In an app using `UIScene`, `Alert` no longer pops up because the window
that gets created are not attached to a scene.
## Changelog
[iOS] [Fixed] - Fix `Alert` not showing in an app using `UIScene`
Pull Request resolved: https://github.com/facebook/react-native/pull/34562
Test Plan: Use the test plan in https://github.com/facebook/react-native/issues/29295. This should not regress that fix.
Reviewed By: cipolleschi
Differential Revision: D39276976
Pulled By: lunaleaps
fbshipit-source-id: e48e985ed4abec77d6f01a6c17292d664ed88f13
Summary:
D38460203 (https://github.com/facebook/react-native/commit/e6ef0836c132d6b798e2ff1fc1e1a66c7e238e0b) was reverted because it broke OSS, the root cause is that OSS doesn't have MapBuffer module.
Fixed the issue in this diff by moving MapBuffer usage to fb internal class (FBReactModule) and will re-land.
Changelog:
[iOS][Changed] Replace Folly with MapBuffer for passing js error data
Reviewed By: sammy-SC
Differential Revision: D39210957
fbshipit-source-id: dda0e8c55dbd13bc96310e10a3b09ea53978e8bc
Summary:
Changelog: [iOS][Internal] - Rework button/buttons handling on pointer events & add a new test checking for move events on chorded mouse button presses
This is a larger diff that largely stems from implementing a new pointer event platform test about chorded mouse button presses (adapted from https://github.com/web-platform-tests/wpt/blob/master/pointerevents/pointerevent_pointermove_on_chorded_mouse_button.html). In order to implement this test I added a new method, `step`, to an async test instance to allow you to run ad-hoc assertions labeled by the async test (like it's done in the original web platform test).
Once implementing the test I also discovered my current logic for handling the `button` and `buttons` properties was insufficient so I reworked it to handle more/most cases by making the `button` property instead determined by the change in the `buttons` property. This largely works but unfortunately due to what seems to be a bug in UIKit, chorded pointer "up" events receive the wrong button mask values so it's currently impossible to get this test fully passing on iOS. I've since submitted a bug report to Apple but my hopes aren't high that it will be focused on since it's such a niche issue.
Reviewed By: lunaleaps
Differential Revision: D38951159
fbshipit-source-id: 426b7cf7930ed8329151382fafee487493e568de
Summary:
when integrates with swift, the compiler will build clang module based on the *React-Core-umbrella.h*. however, the include chain reaches some c++ headers that are not available from swift. it will cause build error.
this pr adds `#ifdef __cplusplus` guard for it.
## Changelog
[iOS] [Fixed] - Fix React module build error with swift integration on new architecture mode
Pull Request resolved: https://github.com/facebook/react-native/pull/34527
Test Plan:
one thing we didn't figure out is that we require reanimated to repro the build error.
1. `npx react-native init RN070 --version 0.70.0-rc.4`. # can also repro this issue on 0.69
2. `cd RN070`
3. `yarn add react-native-reanimated@next`
4. `cd ios && rm -rf Pods build && RCT_NEW_ARCH_ENABLED=1 pod install`
5. add `import React;` in `main.m` for clang module generation
```diff
--- a/ios/RN070/main.m
+++ b/ios/RN070/main.m
@@ -1,5 +1,6 @@
#import <UIKit/UIKit.h>
+@import React;
#import "AppDelegate.h"
int main(int argc, char *argv[])
```
6. `yarn ios`
Reviewed By: cipolleschi
Differential Revision: D39128716
Pulled By: jacdebug
fbshipit-source-id: d9e9130f99e3b9e5f7807c475a24cdd84880e720
Summary:
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 1/n - Move RCTBundleManager.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirely of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
The other benefit of splitting up the headers like this is that it'll be much easier for developers to navigate between the .h and .mm files.
Reviewed By: philIip
Differential Revision: D38943262
fbshipit-source-id: 90876324de9fae25bf33c7aef820a32d7c6ce2f8
Summary:
The motivation of this PR is for the Alert to follow the same style override (`overrideUserInterfaceStyle` being light/dark) as the one used by the root window (`UIApplication.sharedApplication.delegate.window`).
This is something that has worked previously because `RCTPResentedViewController()` was used to present the Alert (the behavior has changed in https://github.com/vonovak/react-native/commit/f319ff321c4b7c0929b99e3ebe7e1ce1fa50b34c). With the former approach, the alert would "inherit" the `userInterfaceStyle` of the view controller it was presented within (and that one, in turn, would "inherit" from `UIApplication.sharedApplication.delegate.window`).
With the current approach, the "style inheritance" does not work with the view controller being created [here](https://github.com/facebook/react-native/blob/f3db6cc52792e3006a16408df4ae40f3aee19a86/React/CoreModules/RCTAlertController.m#L24).
Because this viewcontroller instance does not have where to "inherit" the styling from, the styling might be different from the rest of the app. This PR fixes that.
## Changelog
[iOS] [Fixed] - fix: RCTAlertController's UserInterfaceStyle to follow root window
Pull Request resolved: https://github.com/facebook/react-native/pull/34218
Test Plan:
Instead of
```
self.overrideUserInterfaceStyle = UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle;
```
you can do
```
self.overrideUserInterfaceStyle = UIUserInterfaceStyleDark;
```
and observe the result. So if the override is set, it'll manifest itself. If it's not set, the value of `UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle` will be `UIUserInterfaceStyleUnspecified`, and it'll have no effect.
<details>
<summary>screenshot</summary>
</details>
Reviewed By: dmitryrykun
Differential Revision: D38660799
Pulled By: cipolleschi
fbshipit-source-id: c979266900e27be7a4732bdb6e9a496906534931
Summary:
Changelog: [iOS][Internal] - Fix buttons property value for non-hoverable pointers
The previous diff ensured that on iOS you could run through the entirety of the non-hoverable pointer event attributes test but that also revealed some failing tests related to the `buttons` property when using a non-hoverable pointer. This diff fixes that by ensuring that we only forward the result of the `buttonMask` to `buttons` when the pointer is a mouse, and assume that it is an emulated left click otherwise.
Reviewed By: lunaleaps
Differential Revision: D38914239
fbshipit-source-id: c573e934d0e9c0ac2af4945dc5360840ddc87d4d
Summary:
Changelog: [iOS][Internal] - Apply pointer entering/leaving tracking to touch-initiated pointer events
This diff takes the refactoring done in the previous diff in this stack and applies it to the pointer events which are converted from discrete touch events. In addition this adds a check when an ActiveTouch is created to see if the pointer in question was hovering before the touch started or not, which is stored and leveraged once the touch is lifted to determine if we should treat the pointer as leaving the screen entirely or not.
Reviewed By: lunaleaps
Differential Revision: D38762330
fbshipit-source-id: 08452783e01bf5944c57b94a292805b2d69d4384
Summary:
Changelog: [iOS][Internal] - Refactor hover tracking to prepare for support of tracking the entering/leaving of poitners on non-hover pointer events
This diff begins the work in preparing the touch handler class to track pointer's entering & leaving of views on events other than a hover move by refactoring it to 1) support multiple/simultaneous pointers and 2) abstract the pointer tracking out of the hover recognizer callback so that it can be used for other events in the future (to be done in future diffs, this diff is simply a refactor and keeps the status quo).
Reviewed By: lunaleaps
Differential Revision: D38760358
fbshipit-source-id: f05629ddaa76daed9a3e59ce5d4af6f62ba83755
