Skip to content
Snippets Groups Projects
Select Git revision
0 result
Search by author
  • Any Author
0 authors
This project is mirrored from https://github.com/facebook/react-native.git. Pull mirroring updated .
  1. Nov 14, 2023
  3. Nov 10, 2023
    • Marek Fořt's avatar
      Symbolicate unhandled promise rejections (#40914) (#41377) · 55c2c33b
      Marek Fořt authored 
      Summary:
For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals.

<img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" />

I created [an issue for discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise.

I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console.

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode.

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests

Pull Request resolved: https://github.com/facebook/react-native/pull/40914

Test Plan:
I simply created a throwing function on a dummy app, and checked the output of the console and the warning view:

```ts
import React from 'react';
import {SafeAreaView, Text} from 'react-native';

async function throwme() {
  throw new Error('UNHANDLED');
}

function App(): JSX.Element {
  throwme();

  return (
    <SafeAreaView>
      <Text>Throw test</Text>
    </SafeAreaView>
  );
}

export default App;
```

Here is the output

<img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" />

Edit: I got the warning window working properly:

<img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737

" width="200" />

Reviewed By: yungsters

Differential Revision: D50324344

Pulled By: javache

fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056

Co-authored-by: default avatarOscar Franco <ospfranco@gmail.com>
      55c2c33b
    • Marek Fořt's avatar
      Fix RNTestProject testing on Android (#41378) · f399afc3
      Marek Fořt authored 
      * Fix RNTestProject testing on Android (#41172)

Summary:
While releasing RN 0.73.0-RC3, we relaized that the e2e test script was bugged for Android when used to test RNTestProject with the `-c` option.

There  were 2 problems:
- The downloaded maven-local was not actually used because it doesn't work with a zip. (We were always downloading a version from Maven)
- The versions of React Native between maven-local and the locally packaged React Native were different.

This change fixes the script by:
- Downloading maven-local
- Unzipping maven-local and passing the new folder to the Android app
- Downloading the React Native version that has been packaged in CI

By unzipping maven-local and using the unzipped folder, we make sure that Android is actually using the local repository.
By downloading both the packaged react native and the maven-local from the same CI workflow, we ensure that the versions are aligned.

This also speeds-up further the Android testing.

While running this change, we also moved the `pod install` step inside the `if (iOS)` branch, so we do not install Cocoapods if we need to test
Android.

[Internal] - Fix Android E2E test script when downloading artefacts from CI

Pull Request resolved: https://github.com/facebook/react-native/pull/41172

Test Plan: Tested locally on both main and 0.73-stable, on both Android and iOS

Reviewed By: cortinico

Differential Revision: D50651448

Pulled By: cipolleschi

fbshipit-source-id: 70a9ed19072119d19c5388e8a4309d7333a08e13

* Backport e2e script changes to main (#41332)

Summary:
Last week, I modified the e2e script to make sure it was working properly with 0.73.
This change backport those changes in main

## Changelog:
[Internal] - Backport e2e script changes

Pull Request resolved: https://github.com/facebook/react-native/pull/41332



Test Plan: Tested locally

Reviewed By: dmytrorykun

Differential Revision: D51025796

Pulled By: cipolleschi

fbshipit-source-id: 89ecd3701eaac4ba4bdde2c640df45a158329158

* Use old REACT_NATIVE_MAVEN_LOCAL_REPO env var

* prettier

---------

Co-authored-by: default avatarRiccardo Cipolleschi <riccardo.cipolleschi@gmail.com>
Co-authored-by: default avatarRiccardo Cipolleschi <cipolleschi@meta.com>
      f399afc3
    • Marek Fořt's avatar
      Make the interop-layer work with components with custom name (#41376) · a304cb43
      Marek Fořt authored 
      * Make the interop-layer work with components with custom name (#41207)

Summary:
This should fix
https://github.com/facebook/react-native/issues/37905#issuecomment-1774851214

When working on react-native-fast-image, we realized that the interop layer does not work for components where the exported name is different from the iOS class.

To fix this, we can use the Bridge to retrieve the actual view manager, given the component name.

This solution should be much more robust than making assumptions on the ViewManager name, given the ComponentName.

On top of that, we realized tha the interop layer was not calling `didSetProps` after setting the props, so we are invoking that.

bypass-github-export-checks

[iOS][Fixed] - Add support for Components with custom names in the interop layer.

Pull Request resolved: https://github.com/facebook/react-native/pull/41207



Test Plan: Tested locally on an app created in 0.72 and 0.73 in Bridge and Bridgeless mode.

Reviewed By: cortinico

Differential Revision: D50698172

Pulled By: cipolleschi

fbshipit-source-id: 49aee905418515b0204febbbe6a67c0114f37029

* Remove references to RCTBridgeProxy

---------

Co-authored-by: default avatarRiccardo Cipolleschi <riccardo.cipolleschi@gmail.com>
Co-authored-by: default avatarRiccardo Cipolleschi <cipolleschi@meta.com>
      a304cb43
  5. Nov 08, 2023
  7. Nov 06, 2023
  9. Nov 03, 2023
  11. Oct 13, 2023
    • Nicola Corti's avatar
      Fix broken Loading/Refreshing indicator on Android · 3a4d79e7
      Nicola Corti authored 
      Summary:
The Loading.../Refreshing... indicator is currently broken on Android.
The reason is related to D42599220
We used to have a Toast shown to users on Android as a fallback, but as the
DevLoadingView is not always loaded as a module in the core package, this ends up in the banner never beign shown to the user (on RN Tester or template apps).

Changelog:
[Android] [Fixed] - Fix broken Loading/Refreshing indicator on Android

Reviewed By: cipolleschi

Differential Revision: D49876757

fbshipit-source-id: 400e002327ebca908e3e7a7f81c5066888ac4e9b
      3a4d79e7
  13. Oct 12, 2023
  15. Oct 11, 2023
    • Tim Yung's avatar
      RN: Switch EventEmitter to `Array.from(...)` (#39525) · 9b3bd637
      Tim Yung authored 
      Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39525

Switches `EventEmitter#emit` to use `Array.from` instead of the spread operator.

This should be functionally identical (with marginally less overhead of the runtime having to determine the type of `registrations`), but there seems to be [some unexpected Babel configurations in the community](https://github.com/facebook/react-native/issues/35577#issuecomment-1723218934) that causes this line of code to do the wrong things.

Although we should independently root cause the Babel plugin configuration problems, this change might provide immediate relief and is also not any worse (e.g. in terms of code readability). This also adds a descriptive comment explaining the intention of the call to `Array.from`.

Changelog:
[Fixed][General] - Fix a potential bug in `EventEmitter` when used with certain Babel configurations that incorrectly polyfill the spread operator for iterables.

Reviewed By: javache

Differential Revision: D49389813

fbshipit-source-id: 7caf63734fc047496afe2f1ed6d918c22747258a
      9b3bd637
    • Riccardo Cipolleschi's avatar
      Fix Gemfile, setting Active support to < 7.1.0 (#39828) · 785f91b6
      Riccardo Cipolleschi authored 
      Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39828

Active Suppert released a new Gem which is incompatible with Cocoapods 1.13.0, the latest release, as they removed a method used by cocoapods.

This fix ensures that we install compatible versions of the Gem.

## Changelog:
[iOS][Fixed] - Set the max version of Active support to 7.0.8

Reviewed By: hoxyq

Differential Revision: D49949782

fbshipit-source-id: 278097502d3a416567cc8c0b90090fee4fb21503

# Conflicts:
#	Gemfile
      785f91b6
    • Riccardo Cipolleschi's avatar
      Update Xcode 15 patches to be more robust (#39710) · 355025da
      Riccardo Cipolleschi authored 
      Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39710

Last week Apple released Xcode 15, which required us to ship a workaround for the new linker.
Unfortunately, the previous fix was not good enough and there were some edge cases that were not covered.
For example, in some occasions the flags are read as an array and the `-Wl` and the `-ld_classic` flags were separated and not properly removed when moving from Xcode 15 to Xcpde 14.3.1.

This change fixes those edge cases, with a more robust solution where:
- We convert the flags to a string.
- We trim the string and the values properly.
- We add the flags when running `pod install` with Xcode 15 as the default iOS toolchain.
- We remove the flags when running `pod install` with Xcode <15 as the default iOS toolchain.

## Changelog:
[Internal] - Make the Xcode 15 workaround more robust.

Reviewed By: dmytrorykun

Differential Revision: D49748844

fbshipit-source-id: 34976d148f123c5aacba6487a500874bb938fe99

# Conflicts:
#	packages/react-native/scripts/cocoapods/__tests__/utils-test.rb
#	packages/react-native/scripts/cocoapods/utils.rb
      355025da
  17. Oct 02, 2023
  19. Sep 25, 2023
  21. Sep 19, 2023
    • Riccardo Cipolleschi's avatar
      Add ld_classic flag to Hermes when building for Xcode 15 (#39516) · 2a041cb9
      Riccardo Cipolleschi authored 
      Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39516

With Xcode15, Apple rewrote the C++ linker.
This is a breaking change that does not work with weak symbols.
As a workaround, apple is suggesting to add `-ld_classic` to the linker in order to readd support for weak symbols. The flag does not exists for Xcode 14.3 or lower, so we need to add it conditionally.

With this change, we introduce a couple of checks in the Hermes build logic:
1. Detect the version of Xcode that is used
2. Add the new flag to `HERMES_EXTRA_LINKER_FLAGS` if Xcode version is 15.

[Internal] - Make hermes build properly with Xcode 15

Reviewed By: cortinico, dmytrorykun

Differential Revision: D49368675

fbshipit-source-id: 62d8ed81855c426f56ed94b6a2d6da2eb882b355
      2a041cb9
    • Riccardo Cipolleschi's avatar
      Fix Xcode 15 RC issues (#39474) · 8ccdb2cb
      Riccardo Cipolleschi authored 
      Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39474

When it comes to Xcode 15 RC, we are aware of two issues:
1. `unary_function` and `binary_function` not available in Cxx17
2. [Weak linking](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking) is not supported anymore.

This change should fix both of the issues, adding the flags to allow for `unary_function`and `binary_function` to be called and adding the `-Wl -ld_classic` flag to `OTHER_LDFLAGS` in case Xcode 15 is detected.

[Internal] - add the `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` and the `-Wl -ld_classic` flags to projects when needed

Reviewed By: dmytrorykun

Differential Revision: D49319256

fbshipit-source-id: bb895f1e60db915db79684f71fa436ce80b42111
      8ccdb2cb
    • Riccardo Cipolleschi's avatar
      Bump IPHONEOS_DEPLOYMENT_TARGET to 13.4 for 3rd party pods (#39478) · a5e110ad
      Riccardo Cipolleschi authored 
      Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39478

When testing Xcode 15, we realized that a few pods we do not control directly have the IPHONEOS_DEPLOYMENT_TARGET set to old versions of iOS.
We can update that setting to silence the warning with Cocoapods and this is what this script does.

Notice that bumping that setting generated other warning as some APIs have been deprecated.

[Internal] - Bump min IPHONEOS_DEPLOYMENT_TARGET for 3rd party pods

Reviewed By: dmytrorykun

Differential Revision: D49274837

fbshipit-source-id: 584d105c76d654daa2ecf5eb2f1b9381e70f567a
      a5e110ad
  23. Sep 11, 2023
  25. Sep 06, 2023
  27. Sep 05, 2023
  29. Aug 18, 2023
  31. Aug 16, 2023
  33. Aug 14, 2023
  35. Aug 11, 2023