Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35115
When looking at the new entry point I've realized we have the dynamicLibraryName as first parameter.
As this API is not released yet, let's move it as last.
So users on Java can easily call DefaultNewArchitectureEntryPoint.load(true, true, true)
while now they will have to call DefaultNewArchitectureEntryPoint.load("...", true, true, true)
Users in Kotlin won't be affected by this.
Changelog:
[Internal] [Changed] - Sort parameters in DefaultNewArchitectureEntryPoint
Reviewed By: cipolleschi
Differential Revision: D40793370
fbshipit-source-id: 9dc1569d76a1479a738f8e0f41a4183d7c04538f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35095
This change will make sure that we load the correct JS engine at runtime,
by using the BuildConfig flag that RNGP sets for us.
This will solve a lot of noise in adb logcat for users seeing
stacktraces mentioning failing to load `jscexecutor` library.
This is also a breaking change, but as the API was not widely used nor
advertised in the template, we should be fine by just mentioning this in the release notes.
Changelog:
[Android] [Changed] - Update the template to load the correct JS engine at runtime
Reviewed By: cipolleschi
Differential Revision: D40710597
fbshipit-source-id: d59a7a52b22a9bf273ea89094c6620c3ecf6eb00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35091
This diff refines the DefaultNewArchitectureEntryPoint to make it easier for user to
either turn on Fabric, TurboModules or both.
Changelog:
[Internal] [Changed] - Make it easier for user to toggle only Fabric or TurboModules in New Architecture
Reviewed By: cipolleschi
Differential Revision: D40710596
fbshipit-source-id: 236060b2ebccb1bf25e7f5c0fc15f54c5ce5f608
Summary:
* Add a DevToolsSettingsManager, which has android and iOS variants, which uses a new TM (Android) or takes advantage of the Settings TM (iOS) to get/set console patch settings
* This is backed by either the existing Settings module (iOS) or a new Java TM, which uses the SharedPreferences AP
## Testing
Manual testing
## Changelog
[General] [Added] - Add DevToolsSettingsManager
Pull Request resolved: https://github.com/facebook/react-native/pull/34964
Test Plan: * Extensive manual testing
Reviewed By: NickGerleman
Differential Revision: D40333083
Pulled By: rbalicki2
fbshipit-source-id: f3816e3bd7dea3086f6f2269c3a099af14aebb3b
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:
checking for background == null to fix this error:
```java.lang.NullPointerException: Attempt to invoke virtual method 'android.graphics.drawable.Drawable$ConstantState android.graphics.drawable.Drawable.getConstantState()' on a null object reference
at com.facebook.react.views.textinput.ReactTextInputManager.setUnderlineColor(:4)
```
Changelog:
[Internal][Fixed] - check for null background in Android TextInput setUnderlineColor
Reviewed By: beatthat
Differential Revision: D40451369
fbshipit-source-id: 8618d5ff73f517f714c26a0b17af078493822244
Summary:
In this diff I'm shipping and deleting mapBufferSerialization for Text measurement
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348982
fbshipit-source-id: 7336cbe055a55d7d8d4f0a723049842bae1defb5
Summary:
This diff refactors the initialization of MapBuffer so
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348981
fbshipit-source-id: 88bbf4f2370373c20f805c3b23d0ecbe8a26bb86
Summary:
We found this feature crashing the app during hot reload, and as there is no user code dependent on it so far, we decided to disable it until we find the root cause.
changelog: [internal] internal
Reviewed By: mdvacca
Differential Revision: D40445312
fbshipit-source-id: fe28b58c5dca6c91389ad38675ca37669a4965a0
Summary: Changelog: [Internal] Add more properties to PointerEvent, ensure all web platform tests are passing
Reviewed By: mdvacca
Differential Revision: D40314330
fbshipit-source-id: 071683f26f5a1e17d7ea49ac022c0ca23b6f9947
Summary:
Changelog: [Internal] - Add more state to PointerEventState per pointer such that `offset` coordinates and `hitPath` accurately reflect each pointer.
This change eagerly calculates the hitPath of every pointer under a MotionEvent.
Reviewed By: mdvacca
Differential Revision: D39736109
fbshipit-source-id: ef76dc19a86eaf9b26f35c6a55781ece6e43eecc
Summary:
As identified in https://github.com/facebook/react-native/issues/34350, modals do not honor the system's status bar colors because they may not be set by the deprecated `systemUiVisibility` flags. Unless `android:windowLightStatusBar` is set to true, the default flag is a zero-integer (a.k.a. "dark mode", where the icons show as white). Since the `StatusBar` component is using the new `setSystemBarsAppearance` API, the ModalHost should also infer its status bar settings from the same API.
## 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
-->
[Android] [Fixed] - Fixed an issue on Android API 31+ where modals would turn status bar icons white by default
Pull Request resolved: https://github.com/facebook/react-native/pull/34899
Test Plan:
- On a screen with the `StatusBar` bar style set to `dark-content`, the modal also uses white icons
- On a screen with the `StatusBar` bar style set to `light-content`, the modal also uses black icons
### Preview
Here, I change the `barStyle` from `light-content` to `dark-content` and demonstrate that the proper attributes are retained. The "Before" is a recording from `main` and the "After" is this branch. Notice how in "Before", the status bar is always turning the icons white when the modal opens.
|Before|After|
|-|-|
|||
## Other considerations
There's some argument towards removing this check entirely--the status bar appearance should be derived from the theming and/or the parent activity's settings, thereby removing the need to apply separate styling
Reviewed By: lunaleaps
Differential Revision: D40243122
Pulled By: lunaleaps
fbshipit-source-id: ffa56c7d6a1906f89658f95a12f6bf1cefd5be8e
Summary:
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
With this change, if a developer opts into developer support in a release build (i.e. `enableOnCreate == true && ReactBuildConfig.DEBUG == false` in the `DevSupportManagerFactory`), the `PerfTestDevSupportManager` will be used, allowing use of things like heap size reporting and the sampling profiler.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D39468561
fbshipit-source-id: cb3c82e7a8ee74316b23f57dc8d0cc6e5cdb18a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34927
The changes made in D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) and D36958882 (https://github.com/facebook/react-native/commit/d8c25ca1b62df2b93f70bbb1f7b379643ab9ccd4) attempted to reduce flickering and consistency issues when using Animated.
In the old renderer, we explicitly reset all animated props, and wait for the subsequent React commit to set the props to the right state, but if `initialProps` are used, the React reconciliation may not be able to identify the prop-update is required and will leave out the value. This behaviour is different in the new renderer, where we do not explicitly `restoreDefaultValues` on detaching the animated node, and instead rely on the latest state being correct(?).
Changelog:
[General][Fixed] Stop styles from being reset when detaching Animated.Values in old renderer
Fixes#34665
Reviewed By: rshest
Differential Revision: D40194072
fbshipit-source-id: 1b3fb1d1f4a39036a501a8a21e57002035dd5659
Summary:
Noticed that we were using a different tag for each pointer event observed (and that weren't clearing these properly when recyling views).
Each of these tags is a hashmap entry and a boxed boolean, so we can do much better by just using a single (boxed) integer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D40077519
fbshipit-source-id: 130e78c3641eaedfa8787644b98763fd4367bc27
Summary:
Create documentation to write C++ ViewManagers in React AR apps
changelog: [internal] internal
Differential Revision: D40119174
fbshipit-source-id: edce0e6b226a30007c39f924b5896fa2267e98b7
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:
Automation tests were hitting issues with view recycling enabled because we use the main tag field to lookup views, and not properly resetting it when recycling.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D40076594
fbshipit-source-id: 5f518b979a23562f7e7fc8271488678e78f50e91
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/34831
Historically we had to download an unzip the fbjni Android Archive to use it.
Here I'm updating the way how we consume to use prefab so we can remove a lot
of unnecessary configuration, also from the app template.
Changelog:
[Internal] [Changed] - Consume fbjni via Prefab
Reviewed By: cipolleschi
Differential Revision: D39964574
fbshipit-source-id: 1b18682c2b36aabb1fc1a3819ca09e575182eae4
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:
Works around a crash identified by Sapienz in D39852058 (https://github.com/facebook/react-native/commit/30411ae1a42e46d0e5a2da494a39ed2767ba8808)
These logs will still be logged to the console, as they were before
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39968830
fbshipit-source-id: 5d7a5d935e85a7d67e7780d95b2253e50888ad90
Summary:
Previously, ViewPropsMapBuffer conversions were hardcoded deep in Android infrastructrue. I've generalized this into a different mechanism to allow any Props struct to support MapBuffer props.
There are still some things that need to be cleaned up and this should be treated as experimental. One thing we likely want to do is remove the hardcoded IDs (fine for codegen'd code; less so for handwritten) and use compile-time-hashed IDs instead with human-readable string names.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708719
fbshipit-source-id: 64603dee7f21828be31346c555d99862dab304ea
Summary:
Instead of having a special flag just for View MapBuffer props, we now use one flag to indicate that MapBuffer should be used for all props; each XShadowNode must set a special trait indicating if that ShadowNode supports MapBuffer props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708718
fbshipit-source-id: b398ec62a0db9c0ff23c0007c5503cf2838c4173
Summary:
This adds the YGGutter enum, used to choose between row/column gap variants (row-gap, column-gap, gap).
This used later in changes from https://github.com/facebook/yoga/pull/1116, in the APIs which deal with setting gap on style on yoga node.
Note the original PR called this `YGGap`, but this ending up leading to a couple public method signatures that could appear ambiguous:
1. `SetGap(YGGap gap, float gapLength)`: Enums like `YGAlign` are the vaues for an `align` prop. `YGGap` controls the variant of the gap (like `YGEdge` does for left/right/top/bottom variants). So the enum reads as if it is the `gapValue`, and it looks like we have two of the same parameter.
2. `SetGap(YGGap gapDirection, float gap)`: This is misleading, because the direction gaps flow is the cross-axis of flex-direction.
3. `GetGap(YGGap gap)`: `gap` is the variant, but looks like an out param.
The [CSS Box Alignment](https://www.w3.org/TR/css-align-3/#column-row-gap) spec refers to these gaps as "Gutters", which removes the ambiguity.
Changelog:
[General][Added] - Add YGGutter Enum
Reviewed By: yungsters
Differential Revision: D39922412
fbshipit-source-id: 4b0baf800fecb3d03560a4267c7fb4c4330fd39e
Summary:
https://github.com/facebook/yoga/pull/1116 adds a new enum. The enum generator is out of date with copyright header, and some codemods, but it also looks like there were manual changes, types added, etc since generation. I fixed up the script to incorporate generating the changes folks made manually, and also added an enum that was previously only added manually to the C ABI.
Changelog:
[General][Fixed] - Fixup Yoga Enum Generator
Reviewed By: yungsters
Differential Revision: D39922252
fbshipit-source-id: b678fa9a43a896873d8c434745bdaf3f16fd991f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34819
This is crashing on A12 because of using the regular Context instead of the application context. That said, this probably makes more sense as a log warning.
Reviewed By: javache
Differential Revision: D39852058
fbshipit-source-id: 1ac93f8cc9ecdb14f60baca175c8ecff2ff42ac0