Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48837
ViewHierarchyUtil is a class with package visibility and it is not used, let's delete it
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D68467507
fbshipit-source-id: d1bd5b279a26fcecb4fed590ad2de75937b54aa6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48827
This teaches the CSSColor parser how to handle these functions.
There are a surprising amount of edge cases here, including many syntactic options added by the CSS Color Module 4 spec, and some technically invalid examples supported by normalize-color, sometimes working in Chrome.
I used the combination of the spec, and existing functionality and tests for `normalize-color`, with the end result supporting a superset of the functionality of both, while being a bit more permissive than either.
I still need to add support for the other color functions, and will probably want to share code here, but for now, just implemented everything for the rgb values as a start.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D68362477
fbshipit-source-id: 62973ba2f8361b6a43c7cf9a96029147f84582d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48826
This ends up being a not uncommon pattern, so lets make it a bit easier.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68359563
fbshipit-source-id: 94283c8815cf9dd2f6c0d52762d21232383fb311
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48825
Right now we preserve the state of the CSSSyntaxParser across multiple data type parse attempts, so long that a data type parser consumes an additional component value. This requires data type parsers to be careful to not consume additional forward tokens if it may lead to parse error. We can make this model a lot simpler by instead resetting the parser to original state on data type parse error.
We also introduce `peekComponentValue`, and visitor-less `consumeComponentValue` as a convenience, to allow data type parsers to view future component values without advancing, even if the data type parser does return a value, without needing to manually clone the parser.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68357624
fbshipit-source-id: 6ff77bab8ac9eabd5dccea52daa85bbd32b5f2b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48823
This diff is fixing the execution of Events that are sent early in the rendering of surfaces.
This diff fixes a bug in the queueing of events that are built with not surfaceId (-1), the fixes is to call getSurfaceManagerForView() to retrieve the proper surfaceId (as we do in the execution of events)
calling getSurfaceManagerForView() has a perf hit, we believe this won't be a problem because this method will only be called in edge cases (no surfaceId and early execution of events)
changelog: [Android][Fixed] Fix execution of early InteropEvents
Reviewed By: shwanton, lenaic
Differential Revision: D68454811
fbshipit-source-id: a79be0b392004e645c48d1683bba774b6b597ca0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48819
Currently, `VirtualizedList-test.js` has a subtle dependency on how asynchronous operations are queued. Specifically, it depends on...
- `Batchinator` to use `setTimeout` for...
- `InteractionManager` to use `setImmediate` for...
- `InteractionManager` to resolve a promise via microtask.
As a consequence, any changes to this queueing logic (e.g. eliminating the unnecessary `setImmediate` and microtask) unnecessarily breaks these unit tests.
This changes the Jest unit tests to instead use `jest. advanceTimersToNextTimer(<step>)` instead of `jest.runOnlyPendingTimers()` so that the unit tests are no longer dependent on these specific queueing logic.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D68449850
fbshipit-source-id: 382b1c0a0d8fade873ccf17a9deb3622a83b8163
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48800
This just converts yet another class from Java to Kotlin
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D68417564
fbshipit-source-id: 167a27f7f80125cc81a4a0ad57952f1149ef4d7d
Summary:
This collapses all the 0.77 changelog from the various RCs into a single entry.
## Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48811
Test Plan: N/A
Reviewed By: robhogan
Differential Revision: D68438948
Pulled By: cortinico
fbshipit-source-id: 0ef57432901198602863e9769cd2662a0f4e30f6
Summary:
This PR adds missing nonnull annotations to make working with Swift better 👍🏻
## Changelog:
[IOS] [ADDED] - Missing nonnull annotations for RCTArchConfiguratorProtocol, RCTUIConfiguratorProtocol.h
Pull Request resolved: https://github.com/facebook/react-native/pull/48817
Test Plan: CI Green
Reviewed By: cortinico, dmytrorykun
Differential Revision: D68443519
Pulled By: cipolleschi
fbshipit-source-id: 53bf128c65421789034f45f637a08ed996684c6f
Summary:
The `ReactNativeVersion.h` file currently contains a `struct` that holds the React Native version (e.g. `1000.0.0`, as individual ints).
For some libraries, we need to conditionally compile out code when using an older React Native version, and that's where library authors usually set compiler flags that hold the react native version - those are usually resolved using a `node require.resolve` script in the Podspec or build.gradle, adding unnecessary complexity.
With this PR this becomes obsolete as we now create a `#define` that holds the React Native version directly - so e.g.
```cpp
#define REACT_NATIVE_VERSION_MAJOR 0
#define REACT_NATIVE_VERSION_MINOR 67
#define REACT_NATIVE_VERSION_PATCH 1
```
..which we can then use to conditionally compile some code in our libraries:
```cpp
#include <React/ReactNativeVersion.h>
#if REACT_NATIVE_VERSION_MINOR >= 76
// new stuff
#else
// fallback
#endif
```
## Changelog:
[INTERNAL] [ADDED] - Added `REACT_NATIVE_VERSION_*` C++ defines to `ReactNativeVersion.h`
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/48813
Test Plan: Just import the header in a library and check if the defines exist!
Reviewed By: cortinico
Differential Revision: D68441049
Pulled By: javache
fbshipit-source-id: 55ac8875e1a3f8ad8b9d12795fed4204e9c5bb77
Summary:
As in the title, follow up from https://github.com/facebook/react-native/issues/48075 which added unit tests for this class.
## Changelog:
[INTERNAL] - Convert com.facebook.react.modules.network.ResponseUtil to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/48781
Test Plan:
```bash
./gradlew :packages:react-native:ReactAndroid:test -Dtest.single=com.facebook.react.modules.network
```
Reviewed By: javache
Differential Revision: D68393938
Pulled By: Abbondanzo
fbshipit-source-id: ed214b29ad9248c2da2e2653e75447b0a7e05a26
Summary:
Was looking into improving some of the type definitions for the `ToastAndroid` component and found out also that some of the options don't work anymore from API 30 – I revamped a bit these definitions to reflect that as I saw questions about it online. These updates could also be added to the website later.
## Changelog:
[GENERAL][CHANGED] - Improve ToastAndroid jsdocs
Pull Request resolved: https://github.com/facebook/react-native/pull/48779
Test Plan: Check the jsdocs look good when using the `ToastAndroid` component in the code.
Reviewed By: cortinico
Differential Revision: D68393949
Pulled By: Abbondanzo
fbshipit-source-id: 4be318062483db5be3825b7b21f540030f6c5b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48765
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates a handful of components in `Libraries/Components` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Components` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: cortinico
Differential Revision: D68330077
fbshipit-source-id: 6bf00c82f72dbcaaa26470d7ea0917639fc3de4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48763
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in `Libraries/BugReporting`, `Libraries/vendor`, `Libraries/Vibration` and `Libraries/YellowBox` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/BugReporting`, `Libraries/vendor`, `Libraries/Vibration` and `Libraries/YellowBox` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: cortinico
Differential Revision: D68329075
fbshipit-source-id: 7079a54ce3631171f8d7559bc33cab014df1d16d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48761
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in Libraries/Blob to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Blob` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: cortinico
Differential Revision: D68326103
fbshipit-source-id: ff0b5e0125987ed44b34c35f39af1eefa9799d8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48799
This change moves the same scripts we have to prepare the HelloWorld project to RNTester.
This is something we forgot to do when we were decoupling the reacrt-native from the community CLI.
This is also the base to start deprecating cocoapods and add more configuration steps for the project.
## Changelog:
[Internal] - Copy cli.js script from HelloWorld to RNTester
Reviewed By: cortinico
Differential Revision: D68413419
fbshipit-source-id: 7cf19d86bd3c1beb0c1e7f3380331174352a1651
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48787
For reasons that will become clear in the next diff, I'm adding more assertions for things like LogBox being called, and the console being called. I also updated the patterns of things like `toHaveBeenCalledWith` vs `toBeCalledWith` so they're consistent throughout the file.
## Changelog:
[internal] - Add tests to ExceptionManager
Reviewed By: hoxyq
Differential Revision: D68397529
fbshipit-source-id: b05073630969c40a86546a6f5c4244836b636ee1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48784
React requires React DevTools to be the first patch for console methods, because it assumes it is the _last_ on the stack called before calling the real console.
This is because React DevTools adds additional formatting for things like StrictMode dimming, and component stack formatting for browser specific consoles like Chrome and Firefox, where the DevTool extension runs.
If it's not the first patch, then other patches (like logging, or LogBox) will pick up the DevTools additions and include them, which breaks other tools (like the issue show in the screen below).
This diff ensures React DevTools is patched before the React Native console reporter by moving it to `setupErrorHandling`.
## Changelog:
[General] [Fixed] - Always patch React DevTools first so StrictMode dim chars are excluded from logs/logbox.
## Other places?
I'm not sure how we should handle this for the console polyfill or inside useAlwaysAvailableJSErrorHandling yet.
## Screens
### Before
3 errors, 1 with ANSI dim chars:
{F1974436874}
### After
Just 1:
{F1974436879}
Reviewed By: hoxyq
Differential Revision: D68380665
fbshipit-source-id: 4f5353bb8da0038088c05ef7414bf91e965c73e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48785
## Overview
This change adds code frames for component stacks if it differs from the call stack frame.
## Background
After adding native stack based stack frames, which we already symbolicate, we had the capability to show a code frame for component stacks as well as the stack frame (if they differ).
However, this usually wasn't that useful, because the native component stack was unlikely to be more useful than the component stack (see the comparisons below for key errors).
## Owner stacks
With owner stacks the component frame is a lot more useful and in many cases are better at showing the location than the call stack frame.
## Example Screens
Before:
{F1974436645}
After (with owner stacks):
{F1974436723}
Changelog:
[General][Added] - Add owner stack code frames to LogBox
Reviewed By: hoxyq
Differential Revision: D68285627
fbshipit-source-id: 541cecbd4786fffd1970d2e85e659757e3f81604
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48782
React currently has a babel transform to replace all `console.error` calls with a special function for RN and www. The function adds component stacks, which doesn't make sense in an owner stack world because:
- not all console.error calls are replaced, creating inconsistency
- oss web users don't append component stacks to console.log any more
- component stacks can be accessed for DEV modals like logbox with `captureOwnerStack`
- owner stacks are already added to the console with createTask if you use console.error directly
- the redirection is the single greatest source of fragility in the logbox reporting pipeline
So we're removing this as part of the owner stack rollout. This should only be enabled with owner stacks.
## Example Screen
Before:
{F1974436644}
After:
{F1974436645}
## Changelog:
[General] [Added] - Add full owner stack support to React Native
Reviewed By: hoxyq
Differential Revision: D68285628
fbshipit-source-id: 9772593d7ac6e012392d18c6796580c14c852074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48770
Splits CSSValueParserTest to be file per data type to better match new structure, before we introduce more complexity and tests for CSS colors.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68351049
fbshipit-source-id: 1a4218e49c8c8adb056fac1dd67f064a4f890775
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48769
Must function notations do not require delimiting commas, with color function "legacy" syntax being an exception.
E.g.
```
rgb() = [ <legacy-rgb-syntax> | <modern-rgb-syntax> ]
rgba() = [ <legacy-rgba-syntax> | <modern-rgba-syntax> ]
<legacy-rgb-syntax> = rgb( <percentage>#{3} , <alpha-value>? ) |
rgb( <number>#{3} , <alpha-value>? )
<legacy-rgba-syntax> = rgba( <percentage>#{3} , <alpha-value>? ) |
rgba( <number>#{3} , <alpha-value>? )
<modern-rgb-syntax> = rgb(
[ <number> | <percentage> | none]{3}
[ / [<alpha-value> | none] ]? )
<modern-rgba-syntax> = rgba(
[ <number> | <percentage> | none]{3}
[ / [<alpha-value> | none] ]? )
```
Theoretically, this should mean an expression like `rgb(1, 2 0)`, which mixes both comma and whitespace delimeters would be malformed, but both Chrome, and RN's existing `normalize-color` package support this, so to make this pattern easier, we add the ability to scan based on using either whitespace or comma as component value delimiter.
Interestingly, the current spec revision also allows `rgb` function with alpha, or `rgba` function without alpha, which Chrome correctly supports, but `normalize-color` does not.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68349385
fbshipit-source-id: 05cd756ee20227af4d9ec20edc9e7cfc8cc2c071
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48768
Right now, if something like `CSSColor` accepted a function notation block (e.g. for `rgb()` syntax), it is given a syntax parser which may extend beyond the scope of the current function block.
This is confusing, but also problematic for the `CSSSyntaxParser` block visiting logic to validate a correct scope exit.
This change makes it so that the `CSSSyntaxParser` passsed to `CSSDataTypeParser` for function and simple blocks is limited to the syntax within the given block. This prevents extra visiblity beyond the block we are trying to parse, and allows the function/simple block visitor to reliably fail parsing if the block is not correctly terminated, or there are unconsumed component values within the block not handled by the data type parser.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68340127
fbshipit-source-id: 402f2eabdf6df7bce99223c966f22c2158103be5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48737
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in Libraries/AppState and Libraries/BatchedBridge to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/BatchedBridge` and `Libraries/AppState` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68275767
fbshipit-source-id: 97dc84c04a8dd9c9022e53fc4595302efc848338
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48745
This is the first step in a series of diff to make RNGP more Gradle-compliant (specifically for the sake of configuration caching).
Specifically the problem in those 2 tasks is that we're accessing `project.copy()` and other
functions from the `project` field.
The project should never be accessed at execution time. See more on this here:
https://docs.gradle.org/8.12/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
This diff fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68282777
fbshipit-source-id: 6d474f266b5bc50fba57c8cd478173c995864bbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48764
When working on the [commit](https://github.com/facebook/react-native/commit/eced906bedf0c3d2bbc592cc27965c88278abae3) I forgot a bit that makes sure the New Architecture was the default.
This is change set the New Arch as default properly in RCTAppDelegate. Plus it refreshes the GHA caches by updating the Podfile.lock
## Changelog:
[Internal] - Ensure that the New Arch is turned on in RCTAppDelegate
Reviewed By: alanleedev
Differential Revision: D68329797
fbshipit-source-id: 9df5f805f7d3506129909f0adae5ff597f33ce3c
Summary:
In the `displayModeToInt()` function, there is no default case defined which is causing the following warning in React Native Windows when trying to build on the New Architecture:
```
##[error]node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): Error C2220: the following warning is treated as an error
D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): error C2220: the following warning is treated as an error [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
##[warning]node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): Warning C4715: 'facebook::react::displayModeToInt': not all control paths return a value
D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): warning C4715: 'facebook::react::displayModeToInt': not all control paths return a value [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
```
Adding the default case removes the warning and resolves the issue. Not sure if using the -1 value in this case is appropriate.
## 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] - Add default case to `displayModeToInt()` function
Pull Request resolved: https://github.com/facebook/react-native/pull/48711
Test Plan: Tested on React Native Windows New Arch application and was able to build successfully.
Reviewed By: javache
Differential Revision: D68265335
Pulled By: rshest
fbshipit-source-id: 4724a4c7391b9bf651a122f5de227a0c5e0b6212
Dawid Małecki
Jakub Piasecki
Mateo Guzmán
David Vacca
Nick Gerleman
Liron Yahdav
Tim Yung
Nicola Corti
Oskar Kwaśniewski
Marc Rousavy
Fabrizio Cucci
Fabrizio Cucci
Iwo Plaza
Riccardo Cipolleschi
Rick Hanlon
Yajur Grover