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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44409
This is kind of a mess.
D56800381 moved us away from code relying on legacy TextLayoutManager, under the assumption we weren't using the old one anymore. It turns out we were still using the legacy TextLayoutManager for the sole case of cached spannables, where we ask FabricUIManager to measure using non-mapbuffer path, and pass the cache key (no underlying attributedstring). After the diff, we call default VM measure function, which returns zero size. This specifically breaks measurements of uncontrolled TextInput components.
This updates that path to use the same TextLayoutManager as we use for everything else.
This model breaks some code which assumes the AttributedString is present, instead of just para attributes. The redundant calls to get fragments is expensive and already something on my radar to fix, but for now, we mostly just no-op, the same way the old TextLayoutManager did when fragments were not set. This needs a good cleanup.
Changelog:
[Android][Fixed] - Fix cached spannable measurement path
Reviewed By: javache
Differential Revision: D56963152
fbshipit-source-id: 6dc0e29f6b63d367be1ba0be82dfbc18c4654ab2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44376
Changelog: [Internal]
In order to make migration a little bit cleaner, I thought it would be nice to implement forward compatibility for RCTCallInvokerModule. This way, the consumer doesn't have to have branching logic when they try to retrieve the callInvoker in their code, and can remove a callsite to the bridge.
Reviewed By: RSNara
Differential Revision: D56807993
fbshipit-source-id: 6c9aa74db15e04b8ab632d230b3e525363a4d1ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44399
Improves the result of `mockComponent` in React Native's Jest environment so that it has an accurate `name` property.
This will be important when React enables deriving component stack locations via error stack frames.
Changelog:
[General][Changed] - `mockComponent` now also mocks `name`
Reviewed By: kassens
Differential Revision: D56914915
fbshipit-source-id: 1bea3e8773c56f70a89d2171c436f85178676373
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44380
* setInterval's second argument is optional, and defaults to 0
* setTimeout is spec'ed to return a positive integer.
There's also no need to use HostObjects here to represent the timer index, it just hurts performance and makes this code more complex for no clear reason.
Changelog: [General][Fixed] New architecture timer methods now return integers instead of an opaque object.
Reviewed By: RSNara
Differential Revision: D56863422
fbshipit-source-id: fd3e75303662d865083d01e2bfe8633bac151a0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44385
The current core autolinking is failing if a dependency doesn't have an `android` block.
Instead we should filter out all the dependencies that don't have an `android` definition when generating code.
Fixes https://github.com/reactwg/react-native-releases/issues/276
Changelog:
[Internal] [Changed] - RNGP - Fix core Autolinking attemping to link dependencies without a `android` block
Reviewed By: blakef
Differential Revision: D56876267
fbshipit-source-id: 900b13bec697fceac50c994f277621a10e281410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44377
Changelog: [iOS][Deprecated] deprecate RCTRuntimeExecutorModule
After we make CallInvoker available to native modules, we don't need this. Document it and mark it as deprecated.
Reviewed By: RSNara
Differential Revision: D56848799
fbshipit-source-id: 5628eef01a53bfd29d5b89c0398a938bdd87b0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44378
Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules
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.
Reviewed By: RSNara
Differential Revision: D56807994
fbshipit-source-id: 5c3585356d016a50645eda3af2d3bbe00298b4e4
Summary:
The motiviation of this change is to produce sorted / stable native module schemas which members are alphabetically sorted. The benefit is mainly for verifying test fixtures as now new test cases will be inserted at predicatable spots.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56741776
fbshipit-source-id: 842af73cac3b4859d2074e6a5206015924e87201
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44379
A common pattern to implement `ViewManagerOnDemandReactPackage` is to use a `getViewManagersMap` helper. If we capture `ReactApplicationContext` there, we will indefinitely retain the the very first ReactApplicationContext, and break/leak across reloads. Instead we should pass the `ReactApplicationContext` whenever we construct the ViewManager.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D56838427
fbshipit-source-id: 76583dd7f5564ed29f0dbfcef33d8d288cbb90e0
Summary:
Clean this up, now that there is only one TextLayoutManager.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56801446
fbshipit-source-id: 1b81a16031ab520d06d8935000d5019609f8a254
Summary:
No longer used after last diff.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56801475
fbshipit-source-id: 45320418493cb47cc9df192de3dcc73284005fb4
Summary:
These are all either dead, or duplicate code (e.g. for spannable cache). Let's delete it, so we can get rid of the redundant TextLayoutManager that is no longer getting new updates.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56800381
fbshipit-source-id: 264c2ede43b765ff094d3d3976ad8535579cc4d9
Summary:
This prop was introduced into horizontal <ScrollView/> in D35735978.
**Note:** This prop did not work for bridgeless mode.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56854758
fbshipit-source-id: 2b25296a065b01f11aa04c2ff06cabf64ff5fce1
Summary:
This prop was introduced for horizontal and vertical scrollview in D40642469.
That diff updated the native view configs only.
**Note:** This prop did not work for bridgeless mode.
Partial fix: Add the prop to vertical scrollview: D54223244
Full fix: this diff.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56854757
fbshipit-source-id: aff2da407f4df4575ceb66d3d381a144fa07a8e9
Summary:
The margin/padding props were introduced in this diff: D41267765
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56846578
fbshipit-source-id: 396cab3fdd63d9c630690157a385f1ae53208bb7
Moti Zilberman
Blake Friedman
monholm
Ramanpreet Nara
Nick Gerleman
Pieter De Baets
Alan Lee
Eric Rozell
Stefan Wrobel
Rubén Norte
Ingrid Wang
Ruslan Shestopalyuk
Thomas Nardone
Saad Najmi
Matin Zadeh Dolatabad
Kudo Chien
Phillip Pan
Jesse Watts-Russell
George Zahariev
Riccardo Cipolleschi
Tim Yung
Nicola Corti
Christoph Purrer