Summary:
Updates the default set of `"exports"` condition names in our `ReactNativeEnv` for Jest, so that it aligns with the defaults in React Native CLI (https://github.com/react-native-community/cli/pull/1862).
Also includes a subtle update to how this is accomplished. Instead of overriding `exportConditions()`, we assign to the underlying class property — this allows users (once https://github.com/facebook/jest/pull/13989 is merged) to override `customExportConditions` via [`testEnvironmentOptions`](https://jestjs.io/docs/configuration#testenvironmentoptions-object).
```js
preset: 'react-native',
testEnvironmentOptions: {
customExportConditions: ['test', 'react-native'],
},
```
Changelog: [Internal]
Reviewed By: jacdebug
Differential Revision: D43879056
fbshipit-source-id: 86fffe2b5fdf9d8492d25b8b12a78be75b5fa3be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36471
The previous native web socket API, `RCTSRWebSocket`, appears to be an older version of the one provided as part of [SocketRocket](https://github.com/facebookincubator/SocketRocket). The latter has several improvements, such as the ability to respect proxy settings, which has been requested by a user of a React Native app.
Everything translates over pretty easily, and considering that SocketRocket is already a dependency of Flipper, there doesn't seem to be much additional cost to swapping out the libraries. If we wanted to make things even slimmer, it may even be possible to make the WebSocket library be optional for release builds.
## Changelog
[IOS] [CHANGED] - Use SocketRocket for web socket library
Pull Request resolved: https://github.com/facebook/react-native/pull/36347
Test Plan:
Validated the following:
* The WebSocket test page in RNTester
* Live reloading
Reviewed By: cortinico
Differential Revision: D43768835
Pulled By: javache
fbshipit-source-id: 11e1ac2700bc92991897c594622e6687339bfcbf
Summary:
`Partial` is the new name of `$Partial`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D43993220
fbshipit-source-id: 38e8a6bcfa559857b2ab88efee6b904b387bdc0d
Summary:
There's some problem in the last sync that changes the memoization behavior in some product code. We'll revert and investigate.
Changelog: [internal]
Reviewed By: bvanderhoof
Differential Revision: D44100907
fbshipit-source-id: 233b478dd6f2f29121ac05323047ab6099b6b56c
Summary: Changelog: [Android][Fixed] Fixed text measurement issue related to hyphenation frequency
Reviewed By: makovkastar
Differential Revision: D44093758
fbshipit-source-id: 71b7b6cd862586b673a49f5e6efaf9aeeb25c6e1
Summary:
The `FabricUIManager` module was providing access to the global binding defined by Fabric, adding proper typing for it.
The problem about this module is that it only evaluated the global binding once (during module evaluation) and it cached the result. If this module happened to be loaded before the binding is defined, which can happen in apps using the legacy renderer and Fabric together, this modules caches an `undefined` value indefinitely.
This refactors the module as a getter function to make sure this lazy behavior is handled correctly in the callsites.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D44065186
fbshipit-source-id: 7c5cfe674605f03ecb8ca0dabc4c823e0013da6b
Summary:
Part of Codegen Issue https://github.com/facebook/react-native/issues/34872
> [Codegen 88] Move the Visitor.js file from parsers/flow/Visitor.js to parser-promitives.js. Copy the TSInterfaceDeclaration(node: $FlowFixMe) function and add it to the Visitor.js just copied. Remove the parsers/typescript/Visitor.js. Make sure we use the same Visitor in both parsers. (We will end up with a Visitor that is the union of the two, being able to handle both Flow and TS. In this specific case, this trade-off make sense as it allows us to remove one file, several duplicated lines for a small price.)
## 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
-->
[Internal][Changed] - Extract Visitor function to parsers primitives and remove both parsers visitor files
Pull Request resolved: https://github.com/facebook/react-native/pull/36459
Test Plan:
```
yarn jest
yarn flow
yarn lint
yarn format-check
```
Reviewed By: cortinico
Differential Revision: D44021825
Pulled By: cipolleschi
fbshipit-source-id: ea465404830402c44081143ee0539107dc75776c
Summary:
Recent integration from Windows brought in PerformanceApiExample that uses relative pathing to access react-native library. This causes us to have to override the file since our file structure is different. https://github.com/microsoft/react-native-windows/issues/11373
This PR changes the example to use module pathing instead.
## Changelog
[GENERAL] [CHANGED] - Change PerformanceApiExample to use ModulePathing
Pull Request resolved: https://github.com/facebook/react-native/pull/36478
Test Plan: Tested and passed Windows tests
Reviewed By: rshest
Differential Revision: D44089501
Pulled By: javache
fbshipit-source-id: 99993a4f81556b4fef7c5d15af26b20df960ebf9
Summary:
This PR adds a `functionTypeAnnotation` function to the codegen Parser class and implements it in the Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872, refactoring the `throwIfModuleTypeIsUnsupported` function to accept a `Parser` instead of a `ParserType` and use the newly created function instead of the `if (language)` logic.
## Changelog
[Internal] [Added] - Add `functionTypeAnnotation` to codegen Parser class
Pull Request resolved: https://github.com/facebook/react-native/pull/36468
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green
Reviewed By: cipolleschi
Differential Revision: D44056853
Pulled By: rshest
fbshipit-source-id: f22b9efe53df16f7916eb1a9cea8b9531f1194f5
Summary:
## Changelog:
[Internal] -
Now that Performance API implementation is getting close to the final stage, it should be safe to replace the `global.performance` instance with the corresponding new implementation. This is done *only* if the actual native implementation is present, however (otherwise the behaviour will be exactly the same as before). Currently this is the case for all VR apps, Catalyst and very soon will be the case for fb4a/ios.
Reviewed By: cipolleschi
Differential Revision: D44057951
fbshipit-source-id: 7ccff4a4930175def69ef4d8a44335fbbd4a5df4
Summary:
For the TurboModule interop layer, we'll pass in a second ModuleProvider. We'll default that second parameter to null, when the interop layer is disabled. This change will make that easier.
Changelog: [General][Changed] - Re-organize the parameters of TurboModuleBinding::install()
Reviewed By: javache, cortinico
Differential Revision: D43993199
fbshipit-source-id: 2d339cab1f9bfe481f4b72401caa203cd7536da1
Summary:
CellRendererComponent can be given a more useful description, and more constrained type, to ensure it is used more correctly.
Changelog:
[General][Fixed] - Fix types + documentation for CellRendererComponent
Reviewed By: yungsters
Differential Revision: D43925572
fbshipit-source-id: 26aae6a2df989993c97709ffbf1544df7cbae036
Summary:
There is a rounding issue in layout calculation when using onTextLayout method in Text component on Android.
As you can see in the example below onTextLayout returns 3 lines, but in fact text is rendered in 2 lines:
<img width="775" alt="Screenshot 2023-02-19 at 23 48 53" src="https://user-images.githubusercontent.com/8476339/220177419-de183ccd-a250-4131-ad05-907fdb791c75.png">
This happens because `(int) width` casting works like `Math.floor`, but after changing it to `Math.round` we get correct result:
<img width="775" alt="Screenshot 2023-02-19 at 23 51 11" src="https://user-images.githubusercontent.com/8476339/220177859-93474c43-ed87-4c1b-986c-2817b29b78be.png">
## Changelog
[ANDROID] [FIXED] - Fix layout width calculation in onTextLayout
<!-- 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/36222
Test Plan:
This issue can be tricky to reproduce as width calculation depends on device width. I'm attaching code that I used to reproduce it. You need to tap on the screen to run through different sentences and sooner or later you will get the one with this rounding issue.
<details>
<summary>Code to reproduce</summary>
```js
import React, { useState, useEffect } from 'react'
import { SafeAreaView, Text, View } from 'react-native'
function App() {
const [state, setState] = useState({
index: 0,
lines: [],
sentences: [],
})
const onTextLayout = (event) => {
const lines = event.nativeEvent.lines
console.log(JSON.stringify(lines, null, 2))
setState(state => ({ ...state, lines }))
}
useEffect(() => {
fetch('https://content.duoreading.io/20-the-adventures-of-tom-sawyer/translations/english.json')
.then(response => response.text())
.then(response => {
setState(state => ({ ...state, sentences: JSON.parse(response) }))
})
}, [])
return (
<SafeAreaView style={{ flex: 1, padding: 30 }}>
<View style={{ flex: 1 }} onTouchStart={() => setState(state => ({ ...state, index: state.index + 1 }))}>
<Text style={{ fontSize: 22 }} onTextLayout={onTextLayout}>
{state.sentences[state.index]}
</Text>
{state.lines.map((line, index) => (
<View
key={index}
style={{
position: 'absolute',
top: line.y,
left: line.x,
width: line.width,
height: line.height,
opacity: 0.3,
backgroundColor: ['red', 'yellow', 'blue'][index % 3],
}}>
</View>
))}
</View>
</SafeAreaView>
)
}
export default App
```
</details>
Reviewed By: christophpurrer
Differential Revision: D43907184
Pulled By: javache
fbshipit-source-id: faef757e77e759b5d9ea26da21c9e2b396dc9ff1
Summary:
This change updates the offline mirrors and remove the need for destinations in Sandcastle jobs, to mitigate the problem with the oss jobs we are facing.
allow-large-files
## Changelog:
[internal] - update offline mirror and don't run tests on simulators
Reviewed By: robhogan, dmytrorykun
Differential Revision: D44056468
fbshipit-source-id: c4db37a715eb1307a01a33b1917573f67ed0e2a7
Summary:
The contract here is that `initialScrollIndex` only applies once, right after the components mount. There is other code still relying on live `initialScrollIndex`, which is allowed to become stale. E.g. after removing items.
I looked at a larger change of only ever using `initialScrollIndex` in the start, so we have a consistent value. We also ideally should fix up the logic relying on it for the scroll to top optimization.
That series of changes is more involved than I want to spend time on, so this just avoids the check once we have triggered a scroll, where the rest of the code is UT'd to be permissive if it drifts out of allowed.
Changelog:
[General][Fixed] - Allow out-of-range initialScrollIndex after first scroll
Reviewed By: yungsters
Differential Revision: D43926656
fbshipit-source-id: bd09bd9a9aa6b3b5f07209dac8652c9374a762c4
Summary:
After https://github.com/facebook/react-native/pull/36122 we have two of these. This change consolidates the two category methods to be part of the base RCTConvert class instead.
Changelog:
[iOS][Fixed] - Fix duplicate [RCTConvert UIUserInterfaceStyle:]
Reviewed By: cipolleschi
Differential Revision: D44050929
fbshipit-source-id: dd216545e6194446c593cd693072f3959d653d7f
Summary:
This adds a feature flag to enable all the new DOM traversal and layout APIs (in https://github.com/react-native-community/discussions-and-proposals/pull/607).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D43981608
fbshipit-source-id: 77bb1ee4faaaf30cfc8bb2e493763b168702f498
Summary:
We shouldn't be accessing `nativeFabricUIManager` directly because it's untyped and makes it harder to mock the values.
This migrates all existing usages to the `FabricUIManager` module.
In the long term, we should refactor this global binding as a TurboModule.
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D44029301
fbshipit-source-id: d8300acb5dabe4ba27c7f0242230e203c0e8c674
Summary:
This diff is reverting PR https://github.com/facebook/react-native/pull/33468
Due to an increase of java.lang.IllegalStateException caused by the PR
Original commit changeset: cd80e9a1be8f
Original Phabricator Diff: D38410635
Changelog:
[Android][Fixed] - removed logic that calls the [AccessibilityNodeInfo#setError][10] and [#setContentInvalid][13] method to display the error message in the TextInput - Revert of PR https://github.com/facebook/react-native/pull/33468
Reviewed By: NickGerleman, makovkastar
Differential Revision: D44032331
fbshipit-source-id: 732ed0cf23e4f30ae00c51dace851a3fdfe65c01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36461
This change breaks a dependency cycle between `ReactCommon` and `React-Core`.
`React-Core` depends on `ReactCommon` to have access to the various `TurboModule` native files.
`ReactCommon` depends on `React-Core` because the content of the `core/platform/ios` folder and the `samples` folder needs to access the `RCTBridge` and other files in Core.
To break the circular dependency, we introduced two new `podspecs`:
* `React-NativeModulesApple` for the content of `core/platform/ios`.
* `ReactCommon-Samples` for the content of the `samples` folder.
In this way, the new dependencies are linear as `React-NativeModulesApple` and `ReactCommon-Samples` depends on `React-Core` and `ReactCommon` and `React-Core` only depends on `ReactCommon`.
While doing this, we also make sure that all the include path are aligned, to limit the amount of breaking changes.
## Changelog:
[iOS][Breaking] - Split the `ReactCommon/react/nativemodule/core/platform/ios` and `ReactCommon/react/nativemodule/samples` in two separate pods to break circular dependencies.
Reviewed By: mdvacca
Differential Revision: D44023865
fbshipit-source-id: a97569506350db5735ac5534b1592471de196cbe
Summary:
Changelog: [Internal]
Implements a shim for the NativePerformance TurboModule, which can be used as a mock to unit test the JS side of WebPerformance functionality (in particular, the higher level API logic of `Performance` and `PerformanceObserver` implementations in JS) without need to have the native NativePerformance implementation available (which would otherwise require running some heavy weight e2e tests).
Reviewed By: rubennorte
Differential Revision: D43985454
fbshipit-source-id: da10387c1d70cb0300c077972d3925bc2fad4f5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36438
This makes the `react-native` repository compatible with the next sync from react after the changes in https://github.com/facebook/react/pull/26321 land.
That PR is changing the format of the Fabric instance and we have a few instances where we assume the internal structure of that instance in the repository.
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D43980374
fbshipit-source-id: 718b504ff7c5bb6088c553e0256489b04d92b653
Summary:
## Rationale
JavaTurboModule holds the module object as a JTurboModule. With the TurboModule inteorp layer, JavaTurboModule will also need to hold NativeModule objects.
## Changes
So, this diff makes JavaTurboModule hold the module object as a jobject instead.
This shouldn't impact method dispatch, because method dispatch doesn't rely on the JTurboModule interface.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43918939
fbshipit-source-id: 7cc43dfe2df7571e39bcf4d6f362dde0e500e2fe
Summary:
## Rationale
Better separation of concerns. Less confusion. All the logic around TurboModule HostFunction management is in TurboModule::get(). And TurboModule::createHostFunction() is only responsible for creating the HostFunction. Also, there aren't two TurboModule::get functions, each with different/unclear responsibilities.
## Motivation
The interop layer (i.e: D43918998) will have to override TurboModule::createHostFunction():
- TurboModule::createHostFunction() relies on static functions for method dispatch.
- The interop layer cannot use static functions for method dispatch: interop modules' methods are only be discoverable at runtime.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43918940
fbshipit-source-id: f2ffd210329a10967e9b2f0c925f4990cb470083
Summary:
TurboModuleManager.getOrCreateModule() is responsible for creating TurboModules.
In the future, we'll need this method to create interop NativeModules (i.e: NativeModules that don't implement TurboModule). So, this diff changes the implementation of the method to create NativeModule objects.
In the future, we'll extend the TurboModule create algorithm to create legacy NativeModules, by integrating with TurboModuleManager.getLegacyModule(): D43751055
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D43801536
fbshipit-source-id: d86ef915248d40bea56c6103796a37dd7fb5992a
Summary:
In the future, we'll re-use this interface to create NativeModule objects as well.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D43801529
fbshipit-source-id: 90376086744dc996274663792289e3eba7be56c1
Summary:
- Right now, in the TurboModuleManager, "module" refers to TurboModules.
- In the future, we'll use this cleanup lock for interop modules as well (i.e: NativeModules that don't conform to TurboModule).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43801535
fbshipit-source-id: cecccf8d0005ef11bb0c864515fd284292582e64
Summary:
- Right now, in the TurboModuleManager, "module" refers to TurboModules.
- In the future, we'll use this cleanup lock for interop modules as well (i.e: NativeModules that don't conform to TurboModule).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D43801534
fbshipit-source-id: 1ece9faa1ed564b7024098406deaa60b8a904478
Summary:
- Right now, in the TurboModuleManager, "module" refers to TurboModules.
- In the future, we'll use this cleanup lock for interop modules as well (i.e: NativeModules that don't conform to TurboModule).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D43784169
fbshipit-source-id: dca227374e8d7de319f4fd5556d200ba8b9ac77c
