Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44476
# Changelog:
[Internal] -
This is the last step to converting the whole `modules.debug` module to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D57095966
fbshipit-source-id: 3fcb52528674565a4a2b5c306262e0af11a19e6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44475
# Changelog:
[Internal] -
As the title says, this is preparing to complete the conversion of the whole corresponding module to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D57095896
fbshipit-source-id: 87fe08aec974f5f1327189d0e74c3782c4391e85
Summary:
This pull request fixes an issue where the `selectionColor` prop was not applied to the `TextInput` component on iOS, starting from React Native version 0.74.x.
This issue was introduced in PR [1e68e485](https://github.com/facebook/react-native/commit/1e68e48534aedf1533327bf65f26e5cf5b80127b#diff-b6634353ea5b10a91de24605dc51bdfb50e8ddb652ccd5b9dab194168a69d4b1) which relocated `selectionColor` along with `selectionHandleColor` and `cursorColor` out of `otherProps`. This modification inadvertently prevented `selectionColor` from being passed to the iOS native component.
This change ensures that the `selectionColor` prop is explicitly included in the `RCTTextInputView` component's properties, fixing the regression.
Note: `selectionHandleColor` and `cursorColor` are Android-specific and do not require explicit passing on iOS.
## 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] - Fixed an issue where the `selectionColor` prop was not being applied on the `TextInput` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/44420
Test Plan:
**Environment:** iOS Simulator, React Native 0.74.0.
**Steps to reproduce:**
- Implement a `TextInput` component with the `selectionColor` prop set.
- Run the application on an iOS device or simulator.
- Focus on the TextInput component, write some text and select it.
**Expected Result:** the selection color should match the color provided to the `selectionColor` prop.
**Actual result before fix:** the selection color did not reflect the specified `selectionColor` prop and fell back to the default iOS selection color (blue).
**Screenshots:**
- Before fix:
<img width="1710" alt="before_fix" src="https://github.com/facebook/react-native/assets/17989553/8660068c-55c9-4f55-a788-f96eb681fb70">
- After fix:
<img width="1710" alt="after_fix" src="https://github.com/facebook/react-native/assets/17989553/93c9eb26-7da0-4957-b54f-8444aff7e374">
Reviewed By: javache
Differential Revision: D57017836
Pulled By: NickGerleman
fbshipit-source-id: 263ce22168e09c15cdfdb4eb4300a2605d8af032
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44319
The files were identical so no need for both. Having both is error-prone as one may be modified without modifying the other.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56659179
fbshipit-source-id: e5f414f0c4a00c126d301a7fcd26eeb17d74a56c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44491
Changelog: [internal]
Ensure only one scroll event is fired per frame by tracking the events in FabricUIManager
Reviewed By: sammy-SC
Differential Revision: D57018741
fbshipit-source-id: c1ad59f934e359edfeb8f3e084106eebd467a0b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44489
Changelog: [internal]
Integrate a synchronous event API to trigger synchronous scroll events in Android. The API will be changed in the future, this is exposed only for experimentation.
Reviewed By: sammy-SC
Differential Revision: D56886403
fbshipit-source-id: 337277c735c0943ce4ba29bb2d646a72fe101ede
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44451
Changelog: [internal]
Exposing the experimental API EventEmitter::experimental_flushSync to trigger synchronous events from Android. The API will be changed in the future, this is exposed only for experimentation.
Reviewed By: NickGerleman
Differential Revision: D56886402
fbshipit-source-id: 7b71cd489e3bb65dffcfb53fef2ea7cafbb973f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44458
This is the JS plumbing to get it so that views can now use filters. The typing looks like
`filter: [{brightness: 1.5}, {hueRotate: '90deg'}]`
which is different than web which would look like `filter: brightness(1.5) hue-rotate(90deg)`. I feel like the web version is overly complicated and not very *react native-y*. Transform uses the array based approach (albeit they also accept a string). Open to changing this but really feel like the web format is silly and bad since it would just involve parsing some arbitrary string.
The diff includes:
* Style sheet changes so typing is valid
* Process function to turn filter format into {name: string, amount: string}
* Test for process function
* View config changes on Android, iOS and ReactNativeStyleAttributes
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56845572
fbshipit-source-id: 5029b5adac29bb863c89f6c699d5693c58cad711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44457
Most filters are not going to work on iOS. It is a long story but essentially there is not a good way to continuously get a snapshot of the view and its descendants to filter.
We can, however, implement `brightness` using `compositingFilter` and blend mode. This is really not documented at all, but if you assign a string representing the blend mode to the [`compositingFilter`](https://developer.apple.com/documentation/quartzcore/calayer/1410748-compositingfilter?language=objc) property on CALayer, it will actually work. The filter we use is [`multiplyBlendMode`](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Reference/CoreImageFilterReference/index.html#//apple_ref/doc/filter/ci/CIMultiplyBlendMode). As the title suggests this just multiplies the two layers. We can apply this to a `_filterLayer` and set its background color to the brightness amount to get the desired results. Most other color filters either operate on the color components dependently (e.g. new red component depends the value in blue and green), or they have addition operations. We can do addition with `linearDodgeBlendMode`, but the order of operations does not work (we multiply, clamp, then add vs. multiply, add, then clamp).
`opacity` is just a multiplier on the CALayer `opacity` property.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56447175
fbshipit-source-id: 6705673dd9dec9fc3ec89e49b583523eec1028b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44455
Title says it all. Right now this ignores drop-shadow as that will be implemented later. Some of this code will need to be adjusted as it is the one filter that takes multiple amounts. But I feel that can be amended later when we get there - after all the `amount` parsing code is just casting to a float at the moment, so we are not locking ourselves into anything.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D54640629
fbshipit-source-id: c8e1206ab46accab3c99614241b8bd9aa252e12c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44453
This works similar to how `transform` is parsed in that it sets tags on the View to actually update the prop when all the prop setters are done being called since the parsing of the array is not very trivial. Besides that it is pretty simple and just calls into `FilterHelper` and uses `setRenderEffect`: https://developer.android.com/reference/android/view/View#setRenderEffect(android.graphics.RenderEffect).
That API is only exposed in version 31 of the SDK so it is gated accordingly.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D54640600
fbshipit-source-id: ad4cde2bed9611f476f4ecb2550c2269965d7917
Summary:
In this pr, I updated the deprecated babel-plugins with their new library. When you enter the npm page of the relevant plugins, it is recommended to implement new packages instead of the deprecated package.
For example :
<img width="1305" alt="Screenshot 2024-05-05 at 17 50 16" src="https://github.com/facebook/react-native/assets/113903710/a58fdac3-79db-4b53-98bd-4c5325a1e560">
## Motivation:
We use the react-native package in our project and aim to upgrade pnpm to the latest version. First, we wanted to clear deprecated warnings. Babel plugin deprecated warnings were caused by the react-native package, so I created this pull request.
Deprecation Warnings from package installing :
<img width="581" alt="Screenshot 2024-05-05 at 17 53 05" src="https://github.com/facebook/react-native/assets/113903710/9c5859a5-f194-43ab-ae35-417dfaacebab">
## Changelog:
[GENERAL][FIXED] - Replace deprecated babel-plugin libraries to fix deprecation warnings on installation
Pull Request resolved: https://github.com/facebook/react-native/pull/44416
Test Plan: CI should pass
Reviewed By: huntie
Differential Revision: D57056843
Pulled By: robhogan
fbshipit-source-id: b75b329bbc2105c31da85e861ef71ffdcbbb0623
Summary:
Changelog: [internal]
This is a new attempt at fixing mounting errors during synchronous state updates after what we tried in https://github.com/facebook/react-native/pull/44015.
That fix didn't work because `dispatchMountItems` actually makes a copy of the mount items that it's going to process, so when we added the mount items to the list they were actually not being picked up by the current processing.
This changes the fix to call `dispatchMountItems` as many times as needed, while there are mount items to process in the list.
Reviewed By: sammy-SC
Differential Revision: D57107212
fbshipit-source-id: 46988a71daae15d70399258f850653046d0790ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44445
The `ReactNativeInternalFeatureFlagsMock` module is not references in the open source repository, so there's no reason it should exist there. This cleans that up.
Changelog:
[Internal]
Reviewed By: kassens
Differential Revision: D57052284
fbshipit-source-id: d220eae2ba76f20ed48742779fbffd5de1f77529
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44444
Changelog: [Internal] - Request bundles with `excludeSource=true` and `sourcePaths=url-server`.
Changes RN's bundle client to request more efficient source maps from Metro by relying on lazy-fetching of source contents.
NOTE: Requires a Metro version with D56952064 and D56952063 (not yet released on npm) to work properly.
Reviewed By: robhogan
Differential Revision: D56952065
fbshipit-source-id: 0ed083ecc64adbd7acf209bb9abd40db24ffc86b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44461
Users would have to do this by manipulating the environment before.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067036
fbshipit-source-id: 6df16c884412578c3b5cae50e26ca37636a7dc5b
Summary:
Minor inconvenience I noticed while doing some testing in a mono-repo.
The current paths points to the android folder, but should point to the project root. Currently the android build fails if one uncomments the folder paths as they are.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Fix incorrect paths in app build.gradle react config block
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fix incorrect paths in app build.gradle react config block
Pull Request resolved: https://github.com/facebook/react-native/pull/44472
Test Plan:
Uncomment the paths are they are and notice the android build error:
```
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
> /xyz/xyz/xyz/xyz/RNPathTester/android/node_modules/react-native/ReactAndroid/gradle.properties (No such file or directory)
```
Use the updated paths and notice the build succeeds 🥳
Reviewed By: GijsWeterings
Differential Revision: D57093768
Pulled By: cipolleschi
fbshipit-source-id: 8472151c74c7aa5c51dc75f9adda6116387bdf99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44436
The backing buffer behind `ReadableMapBuffer` is effectively immutable, so we can make reads of nested MapBuffers work on an inline view of the same buffer. This book-keeping is kept within ReadableMapBuffer (we can not user `ByteBuffer.wrap()` because the fbjni produces ByteBuffer is not array backed).
The main downside I can think of is that the whole buffer is kept in memory until all children buffers leave, but current use-cases don't involve long-term storage of MapBuffer children, so this is probably a better tradeoff.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D57020759
fbshipit-source-id: d2f5a76561fa4a4219fe5022ba62cc96f56ce022
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44398
**Problem:**
`selection` prop is not being set on component creation.
Not quite sure which RN version this issue was introduced but fixing it on latest code.
Use playground for testing (refer to following diff)
**Proposed Solution:**
Added notes in comments but `viewCommands.setTextAndSelection()` is called only on text or selection update which relies on comparing data with `lastNativeSelection`. Problem is that `lastNativeSelection` is initially set to the props value that is passed in so does not send the command on component creation.
So assign a default selection value of `{start: -1, end: -1}` so it can be set on component creation.
**Changelog:**
[General][Fixed] - `selection` prop in `TextInput` was not being applied at component creation
Reviewed By: cipolleschi
Differential Revision: D56911712
fbshipit-source-id: 7774b246383f85216536040688b0a8ea85b3478a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44432
Implements a bit more of the tokenizer algorithm, to correctly support dimensions like `.25turn` instead of just `0.25turn`.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57033796
fbshipit-source-id: 6d73de22e3a0f0ca0de432be56bca97f0069ad96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44431
Turn `expectTokens()` function into a macro so that GTest assertion macros point to the right line numbers.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D57034303
fbshipit-source-id: f6d18c0d2420e50c75b61a57489e9ddc12653fb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44430
Let's add support for angles so we can correctly represent things like rotation/skew transforms or hue-rotate filter. This should replace `ValueUnit` in prop related transform code.
A couple implementation notes:
1. RN currently uses radians internally, but CSS says the cannonical angle unit is degrees, so we keep to that
2. We have all the information to convert to cannonical value type at parsing layer, so we do that, and clients can only see degreee values instead of units. Less flexible, but simpler/more efficient for now, where higher levels don't care.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D57029378
fbshipit-source-id: 91341f1bf4686d9016823ac8cf91897e933345f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44427
We only need the default module implementation headers in the C++ file. These were added to the header file for the default module helper by mistake.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D57003838
fbshipit-source-id: d37ebd247eaa2c0cb05ebc6c666a585e6352646d
Summary:
After upgrading my app from React Native 0.74.0 to 0.74.1, iOS builds were failing due to the privacy manifest ruby script failing due to what seemed to be a missing nil check.
```
[Privacy Manifest Aggregation] Appending aggregated reasons to existing PrivacyInfo.xcprivacy file.
[Privacy Manifest Aggregation] Reading .xcprivacy files to aggregate all used Required Reason APIs.
[!] An error occurred while processing the post-install hook of the Podfile.
no implicit conversion of nil into Array
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in `+'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in `block (5 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in `block (2 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in `block in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in `get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:18:in `add_aggregated_privacy_manifest'
node_modules/react-native/scripts/react_native_pods.rb:301:in `react_native_post_install'
ios/Podfile:38:in `block (3 levels) in from_ruby'
vendor/bundle/ruby/3.3.0/gems/cocoapods-core-1.15.2/lib/cocoapods-core/podfile.rb:196:in `post_install!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1013:in `run_podfile_post_install_hook'
vendor/bundle/ruby/3.3.0/gems/cocoapods-pod-sign-1.3.0/lib/cocoapods-pod-sign/pod_installer.rb:45:in `run_podfile_post_install_hook'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1001:in `block in run_podfile_post_install_hooks'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:149:in `message'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1000:in `run_podfile_post_install_hooks'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:337:in `block (2 levels) in create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer/xcode/pods_project_generator/pods_project_writer.rb:61:in `write!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:336:in `block in create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:64:in `section'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:315:in `create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:307:in `generate_pods_project'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:183:in `integrate'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:170:in `install!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/command/update.rb:63:in `run'
vendor/bundle/ruby/3.3.0/gems/claide-1.1.0/lib/claide/command.rb:334:in `run'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/command.rb:52:in `run'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/bin/pod:55:in `<top (required)>'
vendor/bundle/ruby/3.3.0/bin/pod:25:in `load'
vendor/bundle/ruby/3.3.0/bin/pod:25:in `<top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:58:in `load'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:58:in `kernel_load'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:23:in `run'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:451:in `exec'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor.rb:527:in `dispatch'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:34:in `dispatch'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:28:in `start'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/exe/bundle:28:in `block in <top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/exe/bundle:20:in `<top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/bin/bundle:25:in `load'
/Users/swrobel/.gem/ruby/3.3.1/bin/bundle:25:in `<main>'
```
Adding some good old `puts` debugging to this file indicated that the problem was that an invalid manifest file was being generated for react-native-image-crop-picker, which I don't understand, because it [doesn't currently have a Privacy Manifest](https://github.com/ivpusic/react-native-image-crop-picker/issues/2040).
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPrivacyTracking</key>
<false/>
<key>NSPrivacyTrackingDomains</key>
<array/>
<key>NSPrivacyCollectedDataTypes</key>
<array/>
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict/>
</array>
</dict>
</plist>
```
It seems there may be some upstream issue in whatever tool generates these missing privacy manifests, but that seemed beyond the scope of a simple nil check.
## Changelog:
[iOS] [FIXED] - Privacy Manifest aggregation failing due to missing nil check
Pull Request resolved: https://github.com/facebook/react-native/pull/44400
Test Plan: Build completes successfully after making this change.
Reviewed By: cipolleschi
Differential Revision: D56921303
Pulled By: philIip
fbshipit-source-id: 1b6b10b05d403bf71f78f5b80543a2d82f043e23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44439
Changelog: [internal]
(IntersectionObserver isn't enabled yet in OSS).
This fixes a bug in `IntersectionObserver` when observing the same target in multiple observers. In that case, the first time we `unobserve` we clean up some metadata that's shared across observers, and other observers observing the target have problems with the missing data.
This fixes the problem by removing the clean up, as the data structure backing this information is a `WeakMap` anyway, so it'll be cleaned up automatically eventually, and the stored data is very small.
Reviewed By: twobassdrum
Differential Revision: D57046864
fbshipit-source-id: b001cf1ae4f4c91b74b1ad487e01691d5f3be1ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44440
# Changelog:
[Internal] -
As in the title, note that there are more files there to migrate, will come separately, to make reviewing easier.
Reviewed By: javache
Differential Revision: D57046953
fbshipit-source-id: e45316da1ed9caaa4daafa96dfabfd374926bd73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44394
Lint fix - flip to a guaranteed non-null value instead of the nullable field
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56898951
fbshipit-source-id: 8740ed77d71a827c7ce80b2df941d24985339619
Summary:
TextInputs' `onTextInput` callback was removed way back in React Native 0.62 with https://github.com/facebook/react-native/commit/3f7e0a2c9601fc186f25bfd794cd0008ac3983ab , but remnants of the implementation exists. Let's just remove it altogether?
## Changelog:
[IOS] [REMOVED] - Remove deprecated onTextInput callback
Pull Request resolved: https://github.com/facebook/react-native/pull/44351
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D56804590
Pulled By: javache
fbshipit-source-id: 89101fa53cdc628a97ba176cf3deca691784bfdd
Summary:
Cocoapods regression is now fixed (been fixed for a while) but we forgot to remove the upper bound and explicit `activesupport` in Gemfile.
https://github.com/CocoaPods/CocoaPods/releases/tag/1.15.2
## Changelog:
[IOS] [CHANGED] - Update Gemfile in template
Pull Request resolved: https://github.com/facebook/react-native/pull/44434
Test Plan: Run `bundle install/update` should update cocoapods to the latest version and active support should work properly without any issues.
Reviewed By: blakef
Differential Revision: D57046638
Pulled By: cipolleschi
fbshipit-source-id: 9d8e716d4392d7bc5a1940b523e57d2193134f95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44362
Packages that are built and directly run in the monorepo no longer need to worry about
conditionally registering themselves to transpile Flow -> JS at runtime. Our build step
strips this file now.
Changelog: [Internal] changes in published packages no longer require conditional calls to Babel register.
Reviewed By: huntie
Differential Revision: D56839521
fbshipit-source-id: 6bec706c639f1ab4138e0b790be8a07654333046
Summary:
https://github.com/facebook/react-native/commit/7af288e5 introduced a breaking change for whoever importing HermesExecutorFactory.h, because the `hermes/inspector-modern/chrome/HermesRuntimeTargetDelegate.h` is not a public header. Also the nested import is not ideal for CocoaPods or use_frameworks.
I think HermesRuntimeTargetDelegate could be an implementation detail that hide from header. This PR tries to turn the ownership declaration from std::optional to std::unique_ptr, so that we could hide the concrete type.
## Changelog:
[IOS] [FIXED] - Fixed `HermesExecutorFactory.h` build error when importing its private header
Pull Request resolved: https://github.com/facebook/react-native/pull/44423
Test Plan: should introduce no breaking change and ci passed
Reviewed By: cipolleschi
Differential Revision: D57041498
Pulled By: huntie
fbshipit-source-id: bfa10c7307458813d99c52313682dd62bea80f19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44415
# Changelog:
[Internal] -
RNTester Image example used hardcoded `https://www.facebook.com/favicon.ico`, which has an uncommon ICO format, for no good reason aside of just this image being served from `facebook.com`.
This diff:
* Replaces the ICO image with a PNG one (which is still served from `facebook.com`
* Factors out all the multiple hardcoded paths into constants, so that it's easier to make such changes in the future
* Changes another image to something that is a bit better on the eyes when severely downscaled
Reviewed By: christophpurrer
Differential Revision: D56978929
fbshipit-source-id: c627d1671c8cb66e9a78f4382faa56e539b2f7b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44414
# Changelog:
[Internal] -
I noticed that "Image/Fade Duration" test in RNTester is practically useless, as at the moment one scrolls to the test, the fading is most probably had already ended.
This adds a "button" to refresh the image and be able to see the fading in again and again, if desired.
Reviewed By: christophpurrer
Differential Revision: D56978930
fbshipit-source-id: 02873b45600ad319b0b1077467f599dc1a54bee3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44413
## Changelog:
[Internal] -
As in the title, the corresponding module is migrated from Java to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D56978931
fbshipit-source-id: e1e8f22ad9bd2f594bc7cf77c6344f8f23996bcc
Summary:
Followup to D56848799!
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D56935723
fbshipit-source-id: 859cd88c06a972b2fb44525eee075df7c701c83a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44381
Changelog: [Android][Added]
I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after #43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API.
this will be forward compatible in the old architecture
Reviewed By: RSNara
Differential Revision: D56866817
fbshipit-source-id: 4096847c52559d9a49feb072a0385da6b64392d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44383
This diff allows the default fallback style to be grabbed from KeyWindow. Previously with the TraitCollections being passed in from overridden views it was not getting the accurate system fallback.
We need this for Twilight, which is adopting a Light/Dark mode toggle. Previously when setColorScheme was getting called it would modify overrideUserInterfaceStyle and that would serve as the "default fallback" for future setColorScheme calls. setColorScheme shouldn't be setting the defaults, it should be setting the user-session theme preference.
Changelog:
[Internal] [Changed] - Added option for treating the KeyWindows's userInterfaceStyle as the source of truth for the system's dark/light mode.
Differential Revision: D56868862
fbshipit-source-id: 229894947baed65ef15cece5bece120e8497462f
Ruslan Shestopalyuk
Robin Shin
Liron Yahdav
Thomas Nardone
Joe Vilches
kaganece
Rubén Norte
Arushi Kesarwani
Tim Yung
Moti Zilberman
Blake Friedman
monholm
Ramanpreet Nara
Nick Gerleman
Pieter De Baets
Alan Lee
Eric Rozell
Stefan Wrobel
Ingrid Wang
Saad Najmi
Matin Zadeh Dolatabad
Kudo Chien
Phillip Pan
Jesse Watts-Russell