Summary:
Working with gabrieldonadel, we realized that static frameworks of the React-RendererRuntime are not following the proper folder structure.
When a user tries to import `ReactCommon/RCTHost` in the app delegate, for example, the user ends up with an error and they can't find the files.
These changes fixes this by establishing the right folder structure in the static frameworks
## Changelog:
[Internal] - Make sure that React-RuntimeCore and JSErrorHandler are created with the proper structure for static frameworks
Pull Request resolved: https://github.com/facebook/react-native/pull/43846
Test Plan:
Tested locally on an app with 0.74.
Before: it failed to build.
After: it build successfully.
Reviewed By: cortinico
Differential Revision: D55741581
Pulled By: cipolleschi
fbshipit-source-id: 11ac0882d3feea05ef8904d55856ba5704b7a3b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43785
Deprecated `UIManager.showPopupMenu()` had success callback that would be triggered on 1) item selection or 2) dismiss.
New `PopupMenuAndroid` only has item selection callback so adding in missing dismiss callback.
Changelog:
[Android][Added] - Add (optional) onPopupDismiss() callback for PopupMenuAndroid
Reviewed By: cortinico
Differential Revision: D55531870
fbshipit-source-id: 26f3992ef6c85fbc6d8dfff00cb723ac4aae3762
Summary:
The React Native ESLint preset currently endorses the Prettier integration that is [explicitly recommended against by Pretier itself](https://prettier.io/docs/en/integrating-with-linters). Notice the difference between these two packages:
- `eslint-config-prettier` is the config that turns off all formatting rules. It's **recommended by Prettier** to be used together with Prettier. You'd still use Prettier itself to actually do the formatting.
- `eslint-plugin-prettier` is a legacy plugin developed a long time ago and that predates most modern Prettier integrations. It runs Prettier as if it were an ESLint rule, applies formatting on `--fix`, and **is not recommended**.
Unfortunately, RN uses the latter one (and always has).
This PR removes `eslint-plugin-prettier` and instead enables `eslint-config-prettier`, as recommended by Prettier.
As a consequence, you'll no longer see squiggly lines in your editor for stuff that isn't actually errors:
<img width="558" alt="Screenshot 2024-04-01 at 20 00 50" src="https://github.com/facebook/react-native/assets/810438/91ae2cec-a9ef-4205-a9ce-6ab858785ed2">
As another consequence, **you'll have to set up your own Prettier step in your pipeline**.
For example, if your precommit hook only contained `eslint --fix`, you'll now also need to run `prettier --write` there as well. Similarly, if you want Prettier to fail CI, you'd need to find where you call `eslint` and also do `prettier --check` there.
Here's an example for how to do it: https://github.com/bluesky-social/social-app/pull/3373
## 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] [BREAKING] - RN ESLint config no longer runs Prettier during ESLint
Pull Request resolved: https://github.com/facebook/react-native/pull/43756
Test Plan:
Tested locally, verified formatting changes no longer get flagged as violations by the RN config.
<img width="470" alt="Screenshot 2024-04-01 at 20 33 55" src="https://github.com/facebook/react-native/assets/810438/515db971-18bc-4625-bb6d-b9d072692923">
Reviewed By: motiz88
Differential Revision: D55643699
Pulled By: yungsters
fbshipit-source-id: 97df774275922086f0356ac857d6425713184e39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43816
We should not attempt to load generated classes by the Annotation processor in OSS because we simply don't run it, so those classes will fail to load. I'm short-circuiting the logic here.
This is sustainability work as we got a report for this in OSS a while ago and I never got the time to work on it.
Changelog:
[Internal] [Changed] - Do not attempt to call Class.forName in OSS
Reviewed By: rshest
Differential Revision: D55693479
fbshipit-source-id: 3ec84e2c7940011b48f354058b5099b46065166d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43822
Changelog: [Internal]
# Feature flag cleanup/migration
This migration is part of the new Feature Flag system built by rubennorte. The goal of this migration is to clean up our Feature Flags and consolidate them into a single place, accessible by all platforms.
# In this diff
Replaced `ReactFeatureFlags.useNativeViewConfigsInBridgelessMode` with `ReactNativeFeatureFlags.useNativeViewConfigsInBridgelessMode()`
Reviewed By: cortinico
Differential Revision: D55695173
fbshipit-source-id: e5158a9d5606f16f8e333321bad472f7eb315d0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43811
This class was really old and had a lot of potential NPEs as it was accessing fields that could have been not initialized properly. I'm fixing it here ahead of a Kotlin migration.
Changelog:
[Internal] [Changed] - Mark ReactModalHostView as NullSafe
Reviewed By: fkgozali
Differential Revision: D55690285
fbshipit-source-id: 3e910da6dc43a30f2f86d4f1e9d02ead006a31c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43814
This is just an example on how to use the NullSafe annotation
Changelog:
[Internal] [Changed] - Annotate AndroidUnicodeUtils as NullSafe
Reviewed By: alanleedev
Differential Revision: D55419929
fbshipit-source-id: 4eac059c5992661ada4ef8d35327dd9a4bc11d25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43815
This moves a lot of classes from Java to Kotlin from the `package com.facebook.react.views.modal`
Changelog:
[Internal] [Changed] - Convert several classes inside `com.facebook.react.views.modal` to Kotlin
Reviewed By: rshest
Differential Revision: D55692067
fbshipit-source-id: 67e93c9d5d5f58add31ca6726c9f1e4ac2e8ffc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43789
This diff introduces some changes to React Native needed to enable fragment-based navigation (see next diff for usage).
Fragment-based navigation will enable us to, instead of re-creating the entire main activity on navigation, create a fragment instead - allowing us to bypass a lot of unnecessary onCreate() logic in our main activity to improve user experience and performance.
Changelog:
[Internal] [Changed] - Add option to skip calling delegate on ReactFragment lifecycle events
Reviewed By: keoskate
Differential Revision: D55646221
fbshipit-source-id: 45b148cb9ecdb1484f1ac714ac2b93ce09c52237
Riccardo Cipolleschi
zhongwuzw
Alex Hunt
Nicola Corti
Samuel Susla
Arushi Kesarwani
Fabrizio Cucci
Alan Lee
dan
Andrew Datsenko
Thomas Nardone
Christoph Purrer
Ruslan Shestopalyuk
Jane Li
Edmond Chui