Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38203
The TurboModule system should just assume that RCTTurboModuleEnabled() is true.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D47074303
fbshipit-source-id: 7b360ff10966d4b20206231f4200f3f474ddff8f
Summary:
Adding paragraphStyle.maximumLineHeight to a iOS UITextField displays the text under the UITextField ([ios-screenshot-1][1], [ios-screenshot-2][2], [ios-screenshot-3][3]). The issue reproduces on Storyboard App (iOS) using UITextField and paragraphStyle.maximumLineHeight. It is not caused by react-native.
[1]: https://user-images.githubusercontent.com/24992535/238834159-566f7eef-ea2d-4fd4-a519-099b0a12046c.png "ios-screenshot-1"
[2]: https://user-images.githubusercontent.com/24992535/238834184-feb454a9-6504-4832-aec8-989f1d027861.png "ios-screenshot-2"
[3]: https://user-images.githubusercontent.com/24992535/238834283-cf572f94-a641-4790-92bf-bbe43afb1443.png "ios-screenshot-3"
The issue is caused by a private class _UITextLayoutFragmentView (a CALayer children of UITextField), which assumes the wrong position when setting the lineHeight. _UITextLayoutFragmentView frame's y coordinates are set to 30, instead of 0 ([react-native-screenshot-1][4], [react-native-screenshot-2][5])
- The _UITextLayoutFragmentView layer does not correctly position
- The issue is caused by adding paragraphStyle.maximumLineHeight to UITextField.attributedText
- The parent UITextField bounds do not correctly position child _UITextLayoutFragmentView.
The issue causes the below text Sdfsd to display under the TextInput.
[4]: https://github.com/Expensify/App/assets/24992535/06726b45-7e35-4003-9fcc-50c8d0dff0f6
[5]: https://github.com/Expensify/App/assets/24992535/d9745d29-8863-4170-bcc3-e78fa7e550d2
I was able to fix the issue and correctly align the private layout view _UITextLayoutFragmentView using the public API RCTUITextField textRectForBound, which allows modifying the UITextField frame and inset.
The solution consists in the following steps, applied only to UITextField with lineHeight prop:
1) set _UITextLayoutFragmentView to vertically align to the top. Required to correctly align _UITextLayoutFragmentView.
2) apply custom bounds with RCTUITextField textRectForBound to align _UITextLayoutFragmentView with the correct y coordinates and height
2) Adjust text baseline to be center aligned
fixes https://github.com/facebook/react-native/issues/28012
## Changelog:
[IOS] [FIXED] - Fix TextInput vertical alignment issue when using lineHeight prop on iOS (Paper - old arch)
Pull Request resolved: https://github.com/facebook/react-native/pull/37465
Test Plan: Extensive test included in the PR comments https://github.com/facebook/react-native/pull/37465#issuecomment-1551459879
Reviewed By: NickGerleman
Differential Revision: D46086661
Pulled By: sammy-SC
fbshipit-source-id: faece0940b153f3525ddcfae9417e943c957a5bf
Summary:
In Webstorm or VSCode when using Typescript the declaration of the class "File" is missing. So both IDEs show "File" as error. With this change it fixes the issue https://github.com/facebook/react-native/issues/38061 .
## Changelog:
[GENERAL] [FIXED] Fixed missing File declaration in Typescript global.d.ts
<!-- 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: https://github.com/facebook/react-native/pull/38165
Test Plan:
I ran
`yarn run test-typescript`
with no error
After that i initialized a new react-native project and installed the react-native library with my local changes of global.d.ts. Webstorm and VSCode now find the declaration of "File" and don't show "File" as error and suggest the right parameters.
Reviewed By: rshest
Differential Revision: D47209461
Pulled By: cortinico
fbshipit-source-id: 0884dfe786ea3a5070aa0a487a8e74463c8f1a0f
Summary:
Adds changelog for new patch.
## 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] - add changelog entry for 0.71.12 and 0.70.11
Pull Request resolved: https://github.com/facebook/react-native/pull/38182
Test Plan: N/A
Reviewed By: GijsWeterings
Differential Revision: D47210080
Pulled By: cipolleschi
fbshipit-source-id: d0df8184a0a6f7848d2bf08102329b73bcb67846
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37688
This moves the `ReactNativeFlipper` classes used to configure Flipper on Android from the template to
a separate Gradle artifact that will be published under the coordinates:
```
com.facebook.react:flipper-integration:0.73.x
```
This reduces the footprint of Flipper on the app template and makes easier for user on 0.73 to migrate
to Kotlin (as they will now have to migrate only 2 files rather than 4).
Changelog:
[Android] [Changed] - Move Flipper integration to a separate Gradle module inside `ReactAndroid`
Reviewed By: huntie
Differential Revision: D46441588
fbshipit-source-id: e197f29b7386b52091b8d38ed09bbd8f74a997df
Summary:
This PR fixed the `id` prop to being correctly mapped to `nativeID` on the following components: `TouchableBounce`, `TouchableHighlight`, ` TouchableNativeFeedback`, and `TouchableOpacity`.
Closes https://github.com/facebook/react-native/issues/38117
Follow up of https://github.com/facebook/react-native/pull/34522
## Changelog:
[GENERAL] [FIXED] - Fix `id` prop not working on `TouchableBounce`, `TouchableHighlight`, ` TouchableNativeFeedback`, and `TouchableOpacity`
Pull Request resolved: https://github.com/facebook/react-native/pull/38169
Test Plan: Ensure that the `id` prop android tests pass on CircleCI
Reviewed By: jacdebug
Differential Revision: D47209319
Pulled By: cortinico
fbshipit-source-id: 50cdf0f1113e067aa46d55e4faaff6818509546e
Summary:
- if an existing iOS project specifies `EXCLUDED_ARCHS`, these settings are overwritten by the `react_native_post_install` step as part of the Cocoapods install
- closes https://github.com/facebook/react-native/issues/35544
### Existing Behaviour
- one of the functions called as part of the `react_native_post_install` step is `exclude_i386_architecture_while_using_hermes`
- see [/packages/react-native/scripts/cocoapods/utils.rb](https://github.com/facebook/react-native/blob/v0.72.1/packages/react-native/scripts/cocoapods/utils.rb#L56-L69)
```
def self.exclude_i386_architecture_while_using_hermes(installer)
projects = self.extract_projects(installer)
# Hermes does not support `i386` architecture
excluded_archs_default = self.has_pod(installer, 'hermes-engine') ? "i386" : ""
projects.each do |project|
project.build_configurations.each do |config|
config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = excluded_archs_default
end
project.save()
end
end
```
🐛 **However** 🐛
- this function is currently called regardless of whether or not you are **actually** using Hermes
- this means existing projects that have `EXCLUDED_ARCHS` set, the existing value will be changed either to `"i386"` or a blank string
### Changed Behaviour
- moved the function call inside an `if ReactNativePodsUtils.has_pod(installer, "React-hermes")` block
- `EXCLUDED_ARCHS` should only be modified if needed now
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] Only modify EXCLUDED_ARCHS when needed for Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/38132
Reviewed By: cortinico
Differential Revision: D47149618
Pulled By: cipolleschi
fbshipit-source-id: cffc2a0d4bc35fa4e933d3f4df6ee85e2f5c4486
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38159
Accessing `RuntimeEnvironment.application` is deprecated and we should instead use `RuntimeEnvironment.getApplication()`
Changelog:
[Internal] [Changed] - Do not directly access RuntimeEnvironment.application in tests
Reviewed By: rshest
Differential Revision: D47186902
fbshipit-source-id: dc28930570e2991da0ad91311f0402fd73af8214
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38101
This adds a few examples of using `MutationObserver` in React Native to RNTester.
`MutationObserver` isn't yet enabled so these shouldn't be accessible normally for the time being.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D46149087
fbshipit-source-id: 8374b5915b8474a17a2f2e3277a9f409f6ab8380
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38100
This creates an experimental subset of MutationObserver. This will not be available yet and is only compatible with the new React Native architecture. This shouldn't show up in the changelog until we're ready to enable this in some form.
Changelog: [Internal]
## Context
This implements a subset of the `MutationObserver` API (as defined on the Web) for React Native.
This subset allows observing nodes added or removed from the UI tree (at any depth) without modifications in user code. This is not possible at the moment and it's required by some performance logging APIs that rely on observability for tracking.
**This is not intended for general use at the moment**. We will continue experimenting with this API and might change important details about how it works.
## Implementation details
This API is implemented as a native module that registers a commit hook in Fabric. Whenever there's a commit in React Native, we check for nodes added or removed from the shadow tree (compared with the previous committed version).
**This implementation is completely cross-platform.**
This API uses a centralized entity in JS and native to handle registration of observers and dispatch of notifications. The dispatch the notifications for all observers in the same callback so we can easily change the sequencing of events easily (for example, we can change this to use microtasks when they're available in RN).
An important aspect to highlight about this is that we call into JavaScript when executing the commit hooks. **We assume that commit hooks that trigger mutations will always happen in the JS thread**, so it's safe to do so. This was necessary because React nullifies all fields in fiber when they're unmounted, and we're reporting nodes being deleted. If we wait too long to get a reference to the public instances, they become unavailable and this API doesn't work correctly. To avoid this we eagerly get references to these public instances right when mutations are being applied, so it's safe.
## Known limitations
* Only the `childList` and `subtree` options are supported.
* There is a feature flag in React Native to do commits in background threads to avoid having to do that work in JS (including layout). This implementation is NOT compatible with that and we're currently working on removing the background executor permanently.
* Notifications from `MutationObserver` are dispatched as regular JavaScript tasks, not as microtasks, and they don't block rendering/mount/paint. Some consequences of that are:
* UI changes done in MutationObserver callbacks are not flushed atomically with the changes being observed. This is caused by the lack of microtasks and because Fabric doesn't wait for them to mount commits in the host platform.
* MutationObserver callbacks cannot reliably set up intersection observers to get a notification for the first paint, as it could have potentially happened already (similar to the previous point).
We are working on infrastructure changes (support for microtasks, blocking paint on microtasks, etc.) to overcome this limitations.
----
Reviewed By: sammy-SC
Differential Revision: D46149086
fbshipit-source-id: be7ba4acd0886d1661a6500d61d2122f34b98b5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38099
A couple of small cleanups after the bulk of the work for `IntersectionObserver` was already merged.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D47056943
fbshipit-source-id: 2a6f9062d91da458f8b980f3abcdc9a4ac86389b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38156
As we migrated several files from Java to Kotlin, our build log got really noisy with several compilation warnings.
That's happing as the Kotlin compiler is stricter than the Java one.
Here I've fixed most of them.
Changelog:
[Internal] [Changed] - Fix multiple warnings post Kotlin migration
Reviewed By: rshest
Differential Revision: D47185820
fbshipit-source-id: f49c90b4a6db9892979ea95b404cf427805c6503
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37978
Tweaks `react-native.config.js` files to remove duplication. `rn-tester` now references framework-included config from `react-native` (ahead of making config additions to this entry point).
As far as I can tell (from historic diff context), the presence of `packages/rn-tester/react-native.config.js` is a special case, due to the CLI's config discovery algorithm, and this file needs to remain a complete config.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D46859698
fbshipit-source-id: 5d31c6ffe43a364f1f2e7d456a6bc15f900be336
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38146
Now that `metro-react-native-babel-transformer` may be loaded from source without transformation, we can remove this workaround / potential footgun.
Jest uses Babel imperatively and doesn't rely on registration (require hooks), so registering within the preprocessor potentially conflicts and has caused problems before. This just tidies up some complexity we don't need.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D47162728
fbshipit-source-id: 06215f9bb7b8e71bcca0429d0bae9f20a22f45a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38145
Add Babel type definitions ahead of moving `metro-react-native-babel-transformer` under `react-natve`.
These are mostly duplicated from https://github.com/facebook/metro, adapted for RN's naming conventions and lint rules.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D47154206
fbshipit-source-id: a44703f6926507732f2f1c65a17e5d4ac590c724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38043
Resorting methods in ReactHost class, this class in very long and to make it easy to read and analyze I'm sorting methods as public -> package -> private
no changes of behavior are happening here
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D46773622
fbshipit-source-id: 4e2867930dc84ef410569532e8a195e491a6a553
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38141
Bump CLI and Metro versions on main to latest.
Changelog:
[General][Fixed] - Bump CLI to 12.0.0-alpha.6, Metro to 0.76.7
Reviewed By: dmytrorykun
Differential Revision: D47153654
fbshipit-source-id: d9eff64e5539f0e577e059bce836af3c65a4a8c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38125
On Android, when using the remote debugging feature (using legacy websockets), it's not safe to assume we can get a `jsi::Runtime` from `JSExecutor`.
Changelog: [General][Fixed] Android does't crash when using remote debugger
Reviewed By: NickGerleman
Differential Revision: D47124234
fbshipit-source-id: 0542da1aca5d411964e3a0833f4c48428ed90c91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38088
For better Kotlin interop we should be using `val` in this interface rather than just `fun`.
This is not a breaking change as Java users can still use `getReactNativeHost()` as before.
Changelog:
[Internal] [Changed] - Use vals inside ReactApplication
Reviewed By: javache
Differential Revision: D47053030
fbshipit-source-id: 4a7fbc71a76be54e1cf7daef499b9bc3e8fc615a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38139
This adds https://github.com/gradle/foojay-toolchains to our build setup.
This will make sure that if the user doesn't have JDK 17 installed, it will be
autodownloaded once they try to build the first time.
Changelog:
[Internal] [Changed] - Add foojay-resolver-convention to auto-download the right JDK
Reviewed By: sammy-SC
Differential Revision: D47129944
fbshipit-source-id: fd49f6dfe5f87ce3f01e5cce3527144fb96f032a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38129
changelog: [iOS] Disable NSTextStorage caching in OSS
A [bug was reported](https://github.com/facebook/react-native/issues/37944) for NSTextStorage caching. Even thought I fixed the bug in D47019250, I want to disable the feature in OSS until the fix is verified in Facebook app.
My plan is to pick this commit for 0.72.1 and reenable NSTextStorage caching once the fix is validated.
Reviewed By: NickGerleman
Differential Revision: D47127912
fbshipit-source-id: 97694e383eb751e89b776c0599969f2c411bac6f
Summary:
While setting up a monorepo that required a custom react-native path location (react-native-macos in my case) I was getting the following error when running `pod install`
That's because `build_codegen` and `checkAndGenerateEmptyThirdPartyProvider` functions don't check if the given `react_native_path` is absolute or relative.
This PR fixes this problem by checking if `react_native_path` starts with `/`
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fix `use_react_native` to support custom react native absolute paths
Pull Request resolved: https://github.com/facebook/react-native/pull/37545
Test Plan:
Modify [rn-tester/Podfile](https://github.com/facebook/react-native/tree/main/packages/rn-tester/Podfile) to use an absolute path when calling `use_react_native`
E.g.
```rb
rn_path = File.dirname(`node --print "require.resolve('react-native/package.json')"`)
use_react_native!(
path: rn_path,
...
)
```
then run `pod install`
Reviewed By: cortinico
Differential Revision: D46279570
Pulled By: cipolleschi
fbshipit-source-id: 0d6da12c5617cfca2c9ef9dea08ecf728a970b6f
Summary:
Adds changelog for new patch.
## 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] - add changelog entry for 0.72.1
Pull Request resolved: https://github.com/facebook/react-native/pull/38131
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D47149515
Pulled By: cipolleschi
fbshipit-source-id: 737032c204d68749770801fa34ecb8d212b8958f
Summary:
This fixes a bug that started with React Native 0.72.0 when using the new architecture and installing a native lib that has Swift code (in my case, `datadog/mobile-react-native`).
Running `pod install` errors with the following output (`DatadogSDKReactNative` is the pod containing the Swift code):
```
[...]
Analyzing dependencies
Downloading dependencies
Installing DatadogSDKReactNative 1.8.0-rc0
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `DatadogSDKReactNative` depends upon `React-Fabric`, `React-graphics`, `React-utils`, and `React-debug`, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
Indeed, this pods were added as dependencies in `packages/react-native/scripts/cocoapods/new_architecture.rb` but do not define modules contrary to the other pods in the list.
This PR is solving a problem that already occured in the past and was solved here: https://github.com/facebook/react-native/pull/33743
It's a new implementation for the PR initially opened here: https://github.com/facebook/react-native/pull/38039
## Changelog:
[IOS] [FIXED] - Fix pod install for libraries using Swift code when the new architecture is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/38121
Test Plan:
1. Clone [this](https://github.com/louiszawadzki/react-native) repo
2. From `main`, add a Swift file to the `MyNativeView` native module in the RN tester app (see inspiration from [this commit](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58))
3. Try to run `RCT_NEW_ARCH_ENABLED=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](https://github.com/facebook/react-native/commit/7b7c3ff530cae07daccc5b5ea6b72d239f913be0) from this PR
6. Both pod install and the subsequent build should succeed.
7. Revert the changes and repeat steps 2 to 6 with `RCT_NEW_ARCH_ENABLED=1 USE_HERMES=1 bundle exec pod install`
Reviewed By: cortinico
Differential Revision: D47127854
Pulled By: cipolleschi
fbshipit-source-id: bf7f65e0d126195a76a0fafbe2f3172f00d5adc1
Ramanpreet Nara
John Ward
Nicola Corti
Intl Scheduler
Fabrizio Bertoglio
Riccardo Cipolleschi
trashcoder
Koichi Nagaoka
Lorenzo Sciandra
Gabriel Donadel
JP
Sam Zhou
Rubén Norte
Luna Wei
Jatin Nagar
Alex Hunt
Rob Hogan
Nick Gerleman
David Vacca
Panagiotis Vekris
Pieter De Baets
Samuel Susla
louiszawadzki
