Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52194
Changelog: [Internal]
Introducing a way to include sources and deps via function that react_native_android_dep.
This will help with Fantom OSS build.
Reviewed By: cortinico
Differential Revision: D77146189
fbshipit-source-id: 06b09d433741506bc1f58fbf1f9e6add9a9cff91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52221
It is currently not possible to use prebuilds, because we are missing the `React-Core-prebuilt.podspec` from the npm package we publish.
This change should fix it.
## Changelog:
[iOS][Added] - Ship the `React-Core-prebuilt.podspec` in the package.json
Reviewed By: cortinico
Differential Revision: D77223271
fbshipit-source-id: ab068e1711fdd86f3f0069dc9aa3c0a591fcd26b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52215
We were not handling the download of the XML properly. Using `Net::HTTP.get` will directly return the body and that won't let us check on the status code of the response.
## Changelog:
[Internal] - use get_response instead of get when downloading the maven metadata
Reviewed By: cortinico
Differential Revision: D77216121
fbshipit-source-id: 4da0abff1624c687977a7b77db8a15f19e6b887d
Summary:
This PR replaces Core Graphics implementation with Core Animation for radial gradients. I found that `endPoints` for radial gradient type works differently than linear gradient type. The `endPoint.x` accounts for horizontal length and `endPoint.y` accounts for vertical. This makes it possible to draw ellipse gradients. So we don't need the core graphics API anymore.
## Changelog:
[IOS] [CHANGED] - Optimised Radial Gradients.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52117
Test Plan: Non breaking change. Test Radial gradient example from RNTester. Compare results with web, android and iOS. Each platform should render the gradients identically.
Reviewed By: rshest
Differential Revision: D77140709
Pulled By: javache
fbshipit-source-id: 6e3ad9fcf8e819d340ccf5f5946beb140e616cb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52122
Would love to have a place with all the edge cases we can come back to when we try and tweak things.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D76942595
fbshipit-source-id: ce6e293e2c068383e54404af71a29a0586dbc04e
Summary:
### The Problem
When trying to measure the location of a `View` within a `ScrollView` (ie. for scrolling to the view), the current recommended method is to use `measureLayout` on the nested view to determine its location inside the containing scroll view:
```tsx
const MyComponent = () => {
const scrollViewRef = useRef<ScrollView>(null);
const nestedViewRef = useRef<View>(null);
const scrollToNestedView = () => {
if (!scrollViewRef.current || !nestedViewRef.current) {
return;
}
nestedViewRef.current.measureLayout(
scrollViewRef.current.getInnerViewNode(),
(x, y) => { scrollViewRef.current.scrollTo({ y, animated: true }); },
);
}
return (
<ScrollView ref={scrollViewRef}>
<View ref={nestedViewRef}>
{ /* content */ }
</View>
</ScrollView>
);
}
```
This is valid in the Typescript types layer. However, the only two methods on `ScrollView` to use in this scenario that are [available in the type definitions](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/ScrollView/ScrollView.d.ts#L830) are `getScrollableNode` and `getInnerViewNode` – both of these methods [return a `number`](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/ScrollView/ScrollView.js#L139-L140). The issue is that a `number` not a valid value to use with `measureLayout` because [its source returns early for that type](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/ReactNative/ReactFabricPublicInstance/ReactFabricHostComponent.js#L91-L102).
(Note, you can also use `findNodeHandle` with the scroll view ref, but this also returns a `number`.)
### The Solution
The long-term solution would be to update the types for both `measureLayout` and `ScrollView`. However, that would constitute a breaking change and require some fairly expansive updates. Instead, I am proposing an additive solution.
`ScrollView` has [a public method called `getNativeScrollRef`](https://github.com/facebook/react-native/blob/e69f0726cd2616fb112d2e4fabfeaafc8cada5d7/packages/react-native/Libraries/Components/ScrollView/ScrollView.js#L142) which returns the underlying `HostInstance`. This method correctly works in the runtime layer, but is not supported in the types layer. This PR exposes the public method in the type definition so that we can properly access the underlying instance without using `ts-ignore`.
## Changelog:[GENERAL] [FIXED] - Expose `ScrollView.getNativeScrollRef` on the type definition to allow accessing the underlying `HostInstance`.
Pull Request resolved: https://github.com/facebook/react-native/pull/52203
Test Plan: None needed. This is only a type update exposing existing functionality.
Reviewed By: cortinico
Differential Revision: D77153959
Pulled By: rshest
fbshipit-source-id: 5880695da85406ed9fe49a1b736b5754db0e6382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52095
This diff removes `shelljs` from `run-ci-javascript-tests.js` and replaces `echo, exec, and exit` methods.
### Motivation
Decrease number of references to `shelljs` across the react-native-github.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D76512374
fbshipit-source-id: 6e02901b570cf9a36bd13a075106a7066a85a2d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52192
Changelog: [internal]
When we shipped the event loop we removed the need to run only expired tasks in `RuntimeScheduler_Modern`, but we never cleaned up the code properly. This does it.
Reviewed By: javache
Differential Revision: D77142978
fbshipit-source-id: f808edf80a134f487723fa36ab7a3593e4efe2d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52191
Changelog: [internal]
Some time ago we added logging for the timer ID in Systrace/Perfetto so we could see where timers were scheduled vs. executed.
This diff adds support for the same functionality for tasks in the runtime scheduler.
Reviewed By: javache
Differential Revision: D77039038
fbshipit-source-id: 792d2fe29b44fb209f9129f46f9d661dad7ebdff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52190
Changelog: [internal]
This adds some tracing metadata to IntersectionObserver to contextualize the performance of certain operations (logging how many observers it's processing).
Reviewed By: javache
Differential Revision: D77039037
fbshipit-source-id: 9cee79ac0509f57e4658a16142f3fe2d10d71fdf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52189
Changelog: [internal]
This creates a benchmark to measure the changes in performance in RuntimeScheduler.
Reviewed By: javache
Differential Revision: D77142979
fbshipit-source-id: 1a6e6824f4c6fdb8d2c5cbad77fb4b8ba406ef29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52138
Integrate React Core prebuilds with apps
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [ADDED] - Added support for using prebuilt RNCore with Cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980286
Pulled By: cipolleschi
fbshipit-source-id: 0ef34599cf7a60e54f799708bce93bcf6fb9d950
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52134
Update RNDependencies podspec to fail fast if framework is missing
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [CHANGED] - Fail fast when pod install i f using prebuild if frameworks are not present in the disk.
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980282
Pulled By: cipolleschi
fbshipit-source-id: 6ab029d0cb06e2f0a3d99ea9fc7b375865e7a966
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52135
Update the xcframework.js script to support Swift
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[INTERNAL] - Update the xcframework.js script to support Swift
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980285
Pulled By: cipolleschi
fbshipit-source-id: 4e5486b79c406ba4b375e2ada24cbe5450e2346f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52137
Update ReactCodegen to support Core prebuilds
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [CHANGED] - Update ReactCodegen to support Core prebuilds
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980283
Pulled By: cipolleschi
fbshipit-source-id: 4b120203e9e1628a63580b0b3b2e882837c0b818
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52136
Update rndependencies.rb to use the same logic of rncore.rb
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[INTERNAL] - Update rndependencies.rb to use the same logic of rncore.rb
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980284
Pulled By: cipolleschi
fbshipit-source-id: a7f09d931c66e2fdf468a09da4be1d40847f472b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52133
Add React-Core-prebuild.podspec to integrate React native core prebuilds using cocoapods
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [ADDED] - Add `React-Core-prebuild.podspec` to integrate React native core prebuilds using cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980281
Pulled By: cipolleschi
fbshipit-source-id: ce102837d6df6ab0fa2e55862cc0c954125bd362
Summary:
Introduce rncore.rb to manage the prebuilds of RNCore.
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
bypass-github-export-checks
## Changelog:
[INTERNAL] - Added script to handle React Core prebuilds
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico, rshest
Differential Revision: D76979549
Pulled By: cipolleschi
fbshipit-source-id: 7a2b1809bf58b600293cc33ca2dcff0060f3fab0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52198
# Changelog:
[Internal] -
This provides an implementation of what was the RnCxx ImageLoaderModule stub inside ReactCxxPlatform, allowing the clients use dependency injection to provide the actual platform specific image loading functionality.
Reviewed By: javache
Differential Revision: D77015269
fbshipit-source-id: 7355dd75692c1f564de8c3daffd6c8a79182dc09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52154
I wasn't able to find any meaningful usage of `EventDispatcherImpl` in OSS, therefore I'm making this class internal.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77024759
fbshipit-source-id: e1ff3329cedf96a8c75edb9b9ccc1ce21adfab11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52150
This is another class moving from Java to Kotlin.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77021952
fbshipit-source-id: 0b04a10bcbe65b7dc14ddd2821f80d90a43f8610
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52195
RNTester is currently instacrashing on release due to use minifying the `ReactModalHostView`.
In that class there is a static method that is accessed by JNI so we should annotated this class
as `DoNotStrip` as otherwise we won't be able to access it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D77148010
fbshipit-source-id: c5b2758fa2919bc1f5885433202a45b4c3f8ff99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52185
It seems like one of the activity on the stack is not properly implementing `DefaultHardwareBackBtnHandler`.
This will make the crash more clear as it will be clear which activity is the one responsible for the crash.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77142320
fbshipit-source-id: 1913976d1ad5d3ceafcfc0569f3b74dad9e919ae
Summary:
Splitting the CHANGELOG as it's getting too big to handle.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: cipolleschi
Differential Revision: D77025333
fbshipit-source-id: cf2d54f2096f9c8c6a3fadb354d0c3065370440d
Alex Hunt
Mateo Guzmán
Andrew Datsenko
Riccardo Cipolleschi
nishan (o^▽^o)
Mo Javad
George Zahariev
Antonio Pires
Joe Vilches
generatedunixname89002005287564
Zane Bauman
Dawid Małecki
Rubén Norte
Christian Falch
Ruslan Shestopalyuk
Nicola Corti
Pieter De Baets
Susmita Horrow
Jakub Piasecki