Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47880
The previous diffs in this stack have aimed to make URL rewriting by inspector-proxy robust to any configuration of device->server, debugger->server and server->server connections.
Though rewriting was originally introduced to support Android emulator networking, we can now expand it to cover other use cases, like the device reaching the server over an internet address not reachable from the dev machine, or the debugger routing to the server through a tunnel on a different port, without needing CORS workarounds.
Changelog
[General][Fixed] dev-middleware: Rewrite URLs in the inspector proxy to cover all configurations, not just Android emulators.
Reviewed By: huntie
Differential Revision: D66247355
fbshipit-source-id: e9201ebc1f7f5fe2119c71cd4d7b4ca895645404
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47681
These were deprecated back in D49262824, so should be safe to remove now.
Changelog: [Android][Removed] Removed hasConstants constructor from ReactModuleInfo
Reviewed By: mdvacca
Differential Revision: D66127070
fbshipit-source-id: 3bd441c96597598470f16c7770c4dfa4ada563a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47680
This was deprecated in D50128456 so should be safe to remove now.
Changelog: [Android][Removed] Removed TurboReactPackage, which was replaced by BaseReactPackage
Reviewed By: mdvacca
Differential Revision: D66127067
fbshipit-source-id: a4090ab439cf99dc693622b8da2c0cffa247ad24
Summary:
Fixes the high contrast color when not specified. Previously, if we didn't specify highContrastLight or highContrastDark, it would create a UIColor with an alpha of 0, which is not what we expected. We should fall back to the dark or light color instead.
## Changelog:
[IOS] [FIXED] - Fabric: Fixes high contrast color when not specified
Pull Request resolved: https://github.com/facebook/react-native/pull/47418
Test Plan:
1. Enable color contrast in iPhone's settings.
2. Open PlatformColor example in RNTester. See dynamic colors
3. color shows correctly
Before:
Reviewed By: javache
Differential Revision: D66303078
Pulled By: cipolleschi
fbshipit-source-id: 63a0d2bc94eea438d4f69643d09825b74575188b
Summary:
Attempting to use the various bridging template and generated C++ Specs for native modules in a project compiling with MSVC does not build.
For the fromJs I had to add `std::move` - otherwise it could not cast.
The supportsFromJs and supportsToJs are changed to address an IntelliSense issue where the template specialization cannot have default members.
## Changelog:
[GENERAL] [FIXED] - Fix C++ bridging template compatibility with MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/47882
Test Plan: It continues to build on Android/iOS builds. And it also builds with MSVC for react-native-windows and other out of tree platforms that use MSVC.
Reviewed By: cipolleschi
Differential Revision: D66360833
Pulled By: javache
fbshipit-source-id: bf97db1cd247a383eb86cac31c601e8ab3400fd2
Summary:
Saw a lot of PRs and push to convert existing Java code to Kotlin, and wanted to contribute to the cause. This is a starting point for me so I can understand more about the Java to Kotlin conversion process for ReactAndroid package.
## Changelog:
- Converted AndroidInfoHelpers to Kotlin class
- Converted AndroidInfoModule to Kotlin object and updated usage of it across the package
Pick one each for the category and type tags:
[ANDROID] [CHANGED] - Migrated systeminfo module code from Java to Kotlin
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/47616
Test Plan: Verified build on local dev environment.
Reviewed By: NickGerleman
Differential Revision: D66258996
Pulled By: javache
fbshipit-source-id: e0958c0be735f54cb20c7daeee1526059edaabcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47484
Small change to types in the base class: all non-primitives return optional from ReadableArray, which matches the semantics in ReadableMap. We already rely on this in some cases, but the current nullability annotations were incorrect, and null values from the array would be passed through from `getMap` and `getArray`.
Changelog: [Android][Breaking] ReadableArray non-primitive getters are now correctly typed as optional
Reviewed By: Abbondanzo
Differential Revision: D65596278
fbshipit-source-id: 5574e9000b07de292bd0da5f1b071aac0eb331d6
Summary:
Changelog: [Internal]
the delegate of TMM is RCTInstance, but RCTInstance doesn't forward all of the APIs and we aren't protected by the compiler because of the optional in TMMDelegate
i found that this backwards compat API did not actually get set up correctly and was never working in the first place... this is why we should avoid optional
long term, TMMDelegate needs to be pushed down to the infra layer and not exist in product, cc blakef
Reviewed By: javache
Differential Revision: D66148789
fbshipit-source-id: 925a6d4ebb6ba6bfb0b1aec6710695e7551ba475
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47892
Update to match the method so it doesn't show as an error in the IDE.
Changelog:[Internal]
Reviewed By: jorge-cab
Differential Revision: D66326667
fbshipit-source-id: f81bdc7763862fc06440b27e417e0b53ad7774da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47889
## Context
When is the runtime ready?
- After the main bundle finishes executing **without** raising a fatal javascript error
## Changes
Let's decorate all errors reported while the runtime is not ready as "[runtime not ready]".
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66316907
fbshipit-source-id: e48542af4f84d4cc3a6ce8f667dbaa10c30c19a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47744
Remove DeprecatedInNewArchitecture for ReactProp annotation
ReactProp is still used in new arch, we might remove this annotation in the future but it will be independent of new arch
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D66216728
fbshipit-source-id: 86d9aeb2932cbf34c57a7a850da0ced5268447bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47783
After the first javascript fatal, the runtime starts tearing down. And it becomes invalid. So, subsequent js fatals will most likely be just noise. Let's filter them out.
This impacts bridgeless mode: both the javascript and c++ pipeline.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66193194
fbshipit-source-id: 61a731850f7ac4f00bfac24e3260673bf94ba8ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47886
We were not scaling border radii properly when they overlap.
We were relying on Android's handling of the issue which is not compliant with the web algorithm leading to **visible gaps between layers when the radii overlapped**
We are now following web spec https://www.w3.org/TR/css-backgrounds-3/#corner-overlap
Changelog: [Android] [Added] Add overlapping radii resolution logic preventing incorrect rendering
Reviewed By: NickGerleman
Differential Revision: D66269809
fbshipit-source-id: 4ab7025dc1e41be6205ff6b828617e1e222536a9
Summary:
The `onLayout` handler of the `KeyboardAvoidingView` view is async due to the `await AccessibilityInfo.prefersCrossFadeTransitions` in `_relativeKeyboardHeight`.
A connected `onLayout` handler will be unable to access the event. Call `persist()` on the event so that it can be accessed asynchronously.
## Changelog:
[GENERAL] [FIXED] - Accessing KeyboardAvoidingEvent event in onLayout handler
Pull Request resolved: https://github.com/facebook/react-native/pull/47798
Test Plan:
The following should not produce an error:
```
import * as React from 'react';
import {
KeyboardAvoidingView,
SafeAreaView,
TextInput
} from 'react-native';
export default function() {
return (
<SafeAreaView>
<KeyboardAvoidingView onLayout={(event) => console.log(event)} behavior="padding">
<TextInput />
</KeyboardAvoidingView>
</SafeAreaView>
);
}
```
Reviewed By: cipolleschi
Differential Revision: D66306085
Pulled By: dmytrorykun
fbshipit-source-id: 9ccf00db79947670ddc7de74a47cc6dc27455fc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47876
Currently, if a device is connected to the bundler via, say, `http://10.0.2.2:8081` (Android default), and a debugger is opened on `http://localhost:8081`, we rewrite hostnames `10.0.2.2.`<->`localhost` so that URLs are correct relative to each.
However, if the debugger is on a different port or protocol, this breaks down - because we only rewrite hostnames.
This fixes that by using the debugger's connecting `Host` header and `encrypted` state to derive the base URL of the server relative to the frontend. We then update the rewriting logic to use this actual full origin (protocol + host) in place of the device-relative origin.
Changelog:
[General][Fixed] dev-middleware: Fix URL rewriting where device and debugger reach the server on different ports/protocols.
Reviewed By: huntie
Differential Revision: D66077627
fbshipit-source-id: 01f6565149caa34b1e9e50dd58deb0122485657c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47872
Largely a refactoring to the way we currently rewrite `url`/`urlRegex` in `Debugger.setBreakpointByURL` CDP requests (debugger->target).
Rewriting regexes is fragile, it only really works if we can assume `'localhost'` appears literally and that ports and protocols don't need changing. The intention here is to freeze the current behaviour so as not to break anyone relying on it (if anyone is), and decouple it from more robust rewriting we want to generalise.
Also adds simple regex escaping to host names (always IPv4 addresses) we inject into regex patterns, since the previous approach could've led to false matches in unlikely edge cases.
Changelog:
[General][Fixed] dev-middleware: Regex-escape IP addresses in urlRegex replacements
Reviewed By: huntie
Differential Revision: D66238782
fbshipit-source-id: 4cd0029081d68c193e36d3713057ffdc7ef0656f
Summary:
currently running jest test, it shows an error:
```
ReferenceError: You are trying to `import` a file after the Jest environment has been torn down. From __tests__/App.test.tsx.
at getState (node_modules/react-native/Libraries/Utilities/Appearance.js:18:26)
at addChangeListener (node_modules/react-native/Libraries/Utilities/Appearance.js:71:19)
at subscribe (node_modules/react-native/Libraries/Utilities/useColorScheme.js:10:66)
at subscribeToStore (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:6232:10)
at commitHookEffectListMount (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:13038:26)
at commitPassiveMountOnFiber (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14461:11)
at commitPassiveMountEffects_complete (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14421:9)
at commitPassiveMountEffects_begin (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14408:7)
at commitPassiveMountEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14396:3)
at flushPassiveEffectsImpl (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16287:3)
at flushPassiveEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16236:14)
at node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16051:9
at workLoop (node_modules/scheduler/cjs/scheduler.development.js:266:34)
at flushWork (node_modules/scheduler/cjs/scheduler.development.js:239:14)
at Immediate.performWorkUntilDeadline [as _onImmediate] (node_modules/scheduler/cjs/scheduler.development.js:533:21)
```
it is a regression from https://github.com/facebook/react-native/issues/46123 that to have a lazy require.
this pr tries to mock `useColorScheme` to return `light`. i think we don't necessarily test the color scheme changes in jest runtime. originally `useColorScheme` also returns `light` because of [this statement](https://github.com/facebook/react-native/blob/9a60038a40e16925ea1adeb3e3c937c22a615485/packages/react-native/Libraries/Utilities/Appearance.js#L77-L83)
## Changelog:
[GENERAL] [FIXED] - Fixed jest error from Appearance.js
Pull Request resolved: https://github.com/facebook/react-native/pull/47629
Test Plan:
```sh
$ npx react-native-community/cli init RN0762 --pm bun --version 0.76.2
$ cd RN0762
$ bun test run
```
Reviewed By: cipolleschi
Differential Revision: D66297456
Pulled By: huntie
fbshipit-source-id: 80d1460532e76bd1815c66964547b50d7f7b3558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47874
We should be searching for the .bat file on Windows to remain compatible with some user setups.
Changelog: [Android][Fixed] look for sdkmanager.bat
Reviewed By: cipolleschi
Differential Revision: D66295240
fbshipit-source-id: 6b79a9aa40f77ed9c5b3d6ad92b1a62e78159223
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47875
The old architecture looks broken because in the OnLoad.cpp file we try to include the autolinking.h header which is only generated when the New Architecture is enabled.
This fix guards the include and the usage of the function provided by the autolinking so that the old architecture should work as well.
## Changelog
[Internal] - Include autolinkin.h in OnLoad.cpp only if it exists
Reviewed By: blakef
Differential Revision: D66295318
fbshipit-source-id: 18461e6b70ac92af57b805bef51c0df49db02283
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47568
Resolves https://github.com/facebook/hermes/issues/1549.
Changelog:
[General][Fixed] - When using Babel with plain JavaScript files, support for additional user syntax plugins should be fixed (now uses Babel's parser instead of hermes-parser). There is no change for JS files annotated with `flow`, where extended JS syntax remains unsupported.
Reviewed By: blakef
Differential Revision: D65816797
fbshipit-source-id: 9f05e86019548ac8727ee65c2e2c417d78a406d8
Summary:
Fixes https://github.com/facebook/react-native/issues/47725
Calling Appearance.setColorScheme(null) or Appearance.setColorScheme(undefined) no longer resets the color scheme useColorScheme returns like on previous rn versions.
## 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
-->
[GENERAL] [FIXED] - Fix `Appearance.setColorScheme(null)` not resetting color scheme value
Pull Request resolved: https://github.com/facebook/react-native/pull/47739
Test Plan: Repo with a patch ready to test: https://github.com/sangonz193/react-native-color-scheme-patch
Reviewed By: yungsters
Differential Revision: D66230236
Pulled By: cipolleschi
fbshipit-source-id: cc668acb1fde6d30f2706fc0ab7dee5cea1c3b14
Summary:
### Problem
The calculated width for a multiline text is based on the longest line. However it does not account for text that wraps.
**Example** if numberOfLines=1 and the text wraps
```
+---------------------------+
This is a long text that
will wrap
+---------------------------+
```
The TextView will render
```
+---------------------------+
This is a long text t...
+---------------------------+
```
because the `calculatedWidth` took the width of the first line.
Also see https://github.com/facebook/react-native/pull/41770#issuecomment-2453611554 for additional context.
### Solution
If the text wraps, take the whole width.
```
+---------------------------+
This is a long text that w...
+---------------------------+
```
Fixes https://github.com/facebook/react-native/issues/39722
Fixes https://github.com/facebook/yoga/issues/1730
## Changelog:
[GENERAL] [FIXED] - Fix text not taking full width
Pull Request resolved: https://github.com/facebook/react-native/pull/47435
Test Plan:
```tsx
<Text
numberOfLines={1}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{'This is a long text that will wrap.'}
</Text>
<Text
numberOfLines={3}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{
'1\n\ntest\nThis is a long text that will wrap.This is a long text that will wrap.This is a long text that will wrap.\n'
}
</Text>
<Text
numberOfLines={3}
style={{
backgroundColor: 'red',
alignSelf: 'flex-start',
color: 'white',
fontSize: 34,
}}>
{
'1\n\nThis is a long text that will wrap.This is a long text that will wrap.This is a long text that will wrap.\n'
}
</Text>
```
1. Verify that the first and third text take full width
2. Verify that the second text does not take full width
| Before | After |
|:------:|:-----:|
| <img width="480" alt="Screenshot 2024-11-05 at 9 00 24 PM" src="https://github.com/user-attachments/assets/b8d765c0-f4b1-42c6-afc7-75862c52612a"> | <img width="480" alt="Screenshot 2024-11-05 at 9 01 49 PM" src="https://github.com/user-attachments/assets/f1534c14-a56a-4d44-8edc-4d9f75166cb2"> |
Reviewed By: NickGerleman
Differential Revision: D65521732
Pulled By: realsoelynn
fbshipit-source-id: 0bb0bb306445e73e8b24ff4c02921739d15ee07e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47754
The `./resolveAssetSource` processor was added to the `defaultSource` prop in the `RCTImageView` static view config in D65819218.
To match this in native view config, we're adding the `customType = "ImageSource"` hint to the view config infra, so it knows to assign correct processor to the native view config in runtime.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66228921
fbshipit-source-id: d0e0cd9e2f5cc0ba5b3a7002f7ade3f45305a2ac
Summary:
RNTester jobs are failing because we bumped folly to the recent version but we didn't update the podfile.lock
## Changelog:
[Internal] - Bump Podfile.lock to new Folly version
Pull Request resolved: https://github.com/facebook/react-native/pull/47868
Test Plan: GHA
Reviewed By: robhogan
Differential Revision: D66292931
Pulled By: cipolleschi
fbshipit-source-id: 19cbe1321d2891135aa9777823e9dff2916b16dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47733
In https://github.com/facebook/yoga/pull/1729 I moved the cleanup of `display: contents` nodes to happen before all the early returns, but that change also made it be called **before** `cloneChildrenIfNeeded`. It actually needs to be called after `cloneChildrenIfNeeded` to make sure that children of `display: contents` nodes are properly owned.
It also needs to be called in every short-path, so it's being called in four places in this PR. Please let me know whether it's ok or not.
X-link: https://github.com/facebook/yoga/pull/1743
Reviewed By: NickGerleman
Differential Revision: D65953902
Pulled By: zeyap
fbshipit-source-id: 0b18a5651f19c23564f5b3aa2a50833426e9ca5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47732
This pull request addresses the issue where combining align-content and align-items properties resulted in incorrect layout behavior in Yoga version 3.1.0, as reported in [Issue https://github.com/facebook/yoga/issues/1739](https://github.com/facebook/yoga/issues/1739).
# Changes Made:
Alignment Logic Update: Modified the alignment calculations to ensure that the combination of align-content and align-items properties produces the expected layout, consistent with CSS Flexbox standards and previous Yoga versions.
Test Cases Added: Introduced new test cases to cover scenarios involving various combinations of align-content and align-items properties to prevent future regressions.
# Testing:
All existing tests pass successfully.
New test cases confirm that the layout behaves as expected when align-content and align-items are used together.
# Impact:
This fix ensures that layouts using both align-content and align-items properties render correctly, aligning with the behavior observed in Yoga version 1.19.0 and standard web browsers.
X-link: https://github.com/facebook/yoga/pull/1742
Reviewed By: joevilches
Differential Revision: D65953882
Pulled By: zeyap
fbshipit-source-id: 7e12a21b1d442b35c3f3536cad32dc4b82130d15
Summary:
- Current implementation does not follow CSS spec for rectangle boxes with corner angles. It is using non spec compliant algorithm to calculate start and end points. This PR follows the spec compliant algorithm to implement and makes sure Web, iOS and Android gradients are identical with corner angles.
- Also, currently it is using `CAGradientLayer` which does not support spec compliant start and end points i.e. start and end point can be outside of rectangle bounds. This leads to inconsistent gradients on iOS for corner angles compared to web and android. So this PR replaces it with `CGGradient`.
- I have also moved some files to make it easier to add more background image types in future.
## Changelog:
[GENERAL] [FIXED] - Linear gradient start and end point algorithm.
<!-- 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/47003
Test Plan:
- Added multiple gradient example which should be identical in all platforms (Web, iOS and Android) and tested thoroughly on all platforms. I think some visual test cases can help here.
- I have referred to [blink's](https://github.com/chromium/chromium/blob/main/third_party/blink/renderer/core/css/css_gradient_value.cc) implementation.
## Aside
Took a while to understand the [spec](https://www.w3.org/TR/css-images-3/#corner-gradient-example), but felt great after getting it. Gradients should be 100% identical on all platforms now. Sorry i missed testing cornered angles + rectangles earlier and I found out it is inconsistent on platforms just this weekend 😅
<img width="1389" alt="Screenshot 2024-10-14 at 12 24 45 AM" src="https://github.com/user-attachments/assets/2f61eb87-502b-4b8c-88f3-d8a3cca9a7a3">
Reviewed By: joevilches
Differential Revision: D64497127
Pulled By: jorge-cab
fbshipit-source-id: 2647176ae2ee74b6c71f9061465b07dccdabcfc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47735
We are trying to remove or minimize private header usage in YogaLayoutableShadowNode.cpp and YogaLayoutableShadowNode.h. There are a few "trivial" ones, meaning some private call maps 1:1 to an existing public API, so I just opt to use that instead
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66131948
fbshipit-source-id: 7068021513703d1c142d3c298f4804e4e8b81ee2
Summary:
This PR fixes the code for generating EventEmitter C++ code in case nested objects in arrays are used.
```typescript
export interface NativeProps extends ViewProps {
onEvent: DirectEventHandler<
Readonly<{
payloadArray: Readonly<
{
obj: Readonly<{ str: string }>
}[]
>
}>
>;
}
export default codegenNativeComponent<NativeProps>('SomeComponent');
```
In this case the generated `EventEmitters.cpp` code would contain:
```c
obj.setProperty(runtime, "str", payloadArrayValue,obj.str);
```
while
```c
obj.setProperty(runtime, "str", payloadArrayValue.obj.str);
```
is expected.
## 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
-->
[GENERAL] [FIXED] - Codegen: Support nested objects in arrays
Pull Request resolved: https://github.com/facebook/react-native/pull/47514
Test Plan: Tested with the reproduction case above to verify correct output.
Reviewed By: javache
Differential Revision: D65848670
Pulled By: elicwhite
fbshipit-source-id: 0021e87bc7213fff615465cab8554cc1a2159522
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47737
We may see an NSRangeException when setting new AttributedString content, where setting the AttributedString itself changes selection (before we mutate it later).
It seems like the selection here is not in a good state yet in regards to the AttributedString backing exposed (since we are reading it while modifying it). So let's fold the logic for updating typing attributes into the collection of ignored work from non-user-selection updates, since programatically setting an AttributedString will already trigger updating typing attributes.
I also added a nil check here, which is unrelated to the crash, but it seems like we should have it for safety...
Changelog:
[iOS][Fixed] - Fix possible NSRangeException when updating typing attributes in response to new text content
Reviewed By: cipolleschi
Differential Revision: D66202986
fbshipit-source-id: fded492b5022c5fef5b9563f93a57549d06a7020
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47738
- updating targetSdk to 35 for RN Android and helloworld
- **Note:** `tagetSdk` of RN Android does not have effect on the app's targetSdk. App can set `targetSdk` regardless of what RN targetSdk is. Updating the targetSdk just signals that RN Android has been tested with targetSdk 35 and apps can choose to support lower targetSdk as needed.
Changelog:
[Android][Changed] updating targetSdk to 35 (apps can still choose their own targetSdk regardless of RN version)
Reviewed By: NickGerleman
Differential Revision: D66209381
fbshipit-source-id: 2f26e8f605a383ff662e4b1d65611f186a7d7979
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47734
- With forced edge-to-edge on Android 15 targetSdk 35, `HermesBadge` overlaps with the top status bar.
- Move the location of the HermesBadge to align with bottom of the header so we can avoid UI overlap with minimal changes to the template.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D66183918
fbshipit-source-id: 6e9eff337660a133349a2813e9ee033a8d2b749e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47707
NewAppScreen should be removed from public API test
Changelog: [Internal]
Reviewed By: cipolleschi, blakef
Differential Revision: D66165484
fbshipit-source-id: 2b72a874e443447a2b444921f25cec729bcb89c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47761
When breaking the last dependency, we created the `RCTApDependencyProvider` in the Codegen pod.
This is not an issue per sè. The problem comes in with the new template in Swift: ReactCodegen contains some headers with some C++ code that Swift can't really process.
That's why most libraries started failing in jobs like [this one](https://github.com/facebook/react-native/actions/runs/11906196751/job/33177904733): the template app was not able to load the `ReactCodegen` pod in the Swift app delegate.
Given that the app delegate only have to actually load the RCTAppDependencyProvider, I extracted that class in its own pod: ReactAppDependencyProvider.
The name of the pod does not follow the React-RCTXXX structure because that will create issues with the import statements and the `use_frameworks!` use case.
> [!NOTE]
> We need to update the template and change the `import ReactCodegen` to `import ReactAppDependencyProvider`
## Changelog:
[iOS][Added] - Extract RCTAppDependencyProvider in the ReactAppDependencyProvider pod
Reviewed By: blakef
Differential Revision: D66241941
fbshipit-source-id: 6b888109c65d9560fff322ec84a16da78fbcd64b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47760
Changelog: [internal]
(this is internal because this API isn't enabled in OSS yet)
This fixes 2 bugs in `MutationObserver`:
1. Incorrectly reporting updates for the same node multiple times, if changes are observable by different targets in the same observer.
2. Incorrectly ignoring observations of subsequent targets in a given observer.
These were caught when migrating the unit tests for `MutationObserver` that were mocking Fabric to a Fantom integration test that uses the whole C++ infra.
Reviewed By: sammy-SC
Differential Revision: D66232571
fbshipit-source-id: b6e967ca4deaa1a69d35f14d4f921103fec2bbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47759
Changelog: [internal]
These interfaces should be available in the global scope, so this exposes them in their setup modules.
Reviewed By: javache
Differential Revision: D66232574
fbshipit-source-id: 191c579ffce3fb8b4b454b5c5725661ff160a46f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47685
Currently, we assume any URL with a hostname of `10.0.2.2` or `10.0.3.2` (device-relative) is eligible for rewriting to `localhost` (frontend-relative), because we assume the device is an Android emulator. We rewrite these URLs between device and dev machine so that the rewritten URLs are reachable from the dev machine.
This diff narrows this logic so that we'll only rewrite URLs where the hostname matches the pre-existing list *and* this matches the host the device is actually connected on, according to its headers from the original connection.
The main motivation for this change is to unblock removing assumptions about device-reachable vs server-reachable hosts. Later in the stack we'll drop the hardcoded listing of `10.0.2.2` etc in favour of identifying URLs that target the dev server, from whatever network.
There's also an edge case fix here that `10.0.2.2` etc might actually refer to a remote LAN server, and not be an Android emulator's alias for for an emulator host.
Changelog:
[General][Fixed] RN DevTools: Don't assume 10.0.2.2 is an alias for localhost unless it's used to establish a connection to the server
Reviewed By: huntie
Differential Revision: D66058704
fbshipit-source-id: bad28717b0c9b1ca43e2ea3391cef13f87892e6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47719
There is a subset of `ImageProps` that are used by Android but not used by iOS. They were missing in the `ImageProps.h`. It was fine when they were only consumed by the Android mounting layer. But it becomes a problem if we want to write some shared C++ code based on those props.
This diff adds those props to the corresponding C++ type.
This should have no practical effect for both platforms.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65426569
fbshipit-source-id: dc1c9fe4a6e0e62e62f84b9b249e1c7d253290f5
Rob Hogan
Pieter De Baets
zhongwuzw
Andrew Coates
Samuel Susla
oddlyspaced
Phillip Pan
Thomas Nardone
Ramanpreet Nara
David Vacca
Jorge Cabiedes Acosta
Matthew Horan
Kudo Chien
Blake Friedman
Riccardo Cipolleschi
Alex Hunt
Santiago
Abdelhafidh Belalia
Dmitry Rykun
Jakub Piasecki
phuccvx12
Nishan
Joe Vilches
Tom Van Laerhoven
Andrei Marchenko
Nick Gerleman
Alan Lee
Rubén Norte