Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36314
## Changelog:
[Internal] - Added support for W3C Performance API extension (Performance,getEntries*)
See [here for the details](https://www.w3.org/TR/performance-timeline/#extensions-to-the-performance-interface).
This only supports `mark` and `measure` performance entry types (not `events`, as those are not supported by browsers either, they recommend using the `PerformanceObserver` API instead).
From the implementation perspective, we already maintained persistent buffer for `mark` entry types, which was required in order to look up measures.
The buffer is circular, limited to 1K entries by default.
I basically mimic the same behavior for `measure` entry types as well, since it's the simplest way of doing it at this point,
If we happen to want adding some other entry types that would be available via `Performance.getEntries*` API in the future, we may want to iterate on the internal data structures representation inside `PerformanceEntryReporter`, but for now I believe this approach should work just fine, and whatever changes we may want to do will be purely internal implementation detail.
Reviewed By: rubennorte
Differential Revision: D43625488
fbshipit-source-id: dd315b3f8488e910749a8e2a4158246e94d76f99
Summary:
## Changelog:
[Internal] -
Noticed this when setting up C++ unit tests for WebPerformance - the change in this diff both makes sure there is no "global constructor" warning generated when `-Wglobal-constructors` is enabled, and also makes this bit potentially a little bit more efficient, as we don't pay for the registry construction if we don't use the WebPerformance API.
Reviewed By: christophpurrer
Differential Revision: D43663521
fbshipit-source-id: 59952f2415f49bb455a3443b3bfd8971108ac72b
Summary:
I was working on `Animated.FlatList` and found some types missing as below
also `Animated.SectionList`
So I refactored type definition for `Animated.FlatList` and `Animated.SectionList` using `abstract class`.
## Changelog
[GENERAL] [FIXED] - add missing FlatList types for Animated FlatList
[GENERAL] [FIXED] - add missing SectionList types for Animated SectionList
<!-- 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/36292
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` with no errors.
Reviewed By: lunaleaps
Differential Revision: D43673884
Pulled By: NickGerleman
fbshipit-source-id: 7ccab5997fa2f22226fb0e106672cee98e568ba4
Summary:
Changelog: [Internal] - Remove all imports back to CJS for changelog in 0.72
We are reverting these imports as it may regress perf as we don't have a recommended inlining solution for ES modules at the current time.
Reviewed By: NickGerleman
Differential Revision: D43630911
fbshipit-source-id: ff3bb80009f327c4d51dad21f2cd287ce46d5964
Summary:
Both Android and iOS allow you to set application specific user interface style, which is useful for applications that support both light and dark mode.
With the newly added `Appearance.setColorScheme`, you can natively manage the application's user interface style rather than keeping that preference in JavaScript. The benefit is that native dialogs like alert, keyboard, action sheets and more will also be affected by this change.
Implemented using Android X [AppCompatDelegate.setDefaultNightMode](https://developer.android.com/reference/androidx/appcompat/app/AppCompatDelegate#setDefaultNightMode(int)) and iOS 13+ [overrideUserInterfaceStyle](https://developer.apple.com/documentation/uikit/uiview/3238086-overrideuserinterfacestyle?language=objc)
```tsx
// Lets assume a given device is set to **dark** mode.
Appearance.getColorScheme(); // `dark`
// Set the app's user interface to `light`
Appearance.setColorScheme('light');
Appearance.getColorScheme(); // `light`
// Set the app's user interface to `unspecified`
Appearance.setColorScheme(null);
Appearance.getColorScheme() // `dark`
```
## Changelog
[GENERAL] [ADDED] - Added `setColorScheme` to `Appearance` module
Pull Request resolved: https://github.com/facebook/react-native/pull/36122
Test Plan:
Added a RNTester for the feature in the Appearance section.
Three buttons for toggling all set of modes.
Reviewed By: lunaleaps
Differential Revision: D43331405
Pulled By: NickGerleman
fbshipit-source-id: 3b15f1ed0626d1ad7a8266ec026e903cd3ec46aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36312
## Changelog:
[Internal] -
`clearMarks` and `clearMeasures` methods are incidental to the `NativePerformance` TurboModule functionality, as in reality this responsibility belongs more on the `NativePerformanceObserver` and `PerformanceEntryReporter` side.
This is something that [the standard indirectly suggests](https://www.w3.org/TR/user-timing/#clearmarks-method) as well (referencing [performance entry buffer](https://www.w3.org/TR/performance-timeline/#dfn-performance-entry-buffer)).
The new implementation should be also a little bit more efficient, as it avoids calling the predicate for each entry.
Finally (and frankly, the main reason for this change, from my perspective), it will simplify mocking/testing the JS part of the PerfAPI code.
Reviewed By: rubennorte
Differential Revision: D43621174
fbshipit-source-id: c4217a0da1d8ecbce797240627f7b4f057d85b97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36307
[Changelog][Internal]
Noticed some JS linter warnings during CircleCI tests being run, this disturbed my OCD, so here's a fix for them.
Reviewed By: cipolleschi
Differential Revision: D43619403
fbshipit-source-id: 779a1d2e197298275d06a2597cfef7554017016f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36237
This changes the data parameter type for `getItemLayout` from a mutable array (too lenient, even before), to `ArrayLike`, which is now the most constrained subset of data which may be passed to a FlatList.
We could do something more exact by adding another generic parameter to FlatList, but that would be likely be noticeably more breaking, since during testing I couldn't manage a pattern that both kept the same minimum number of generic arguments while keeping inference working.
Changelog:
[General][Breaking] - Constrain data type in `getItemLayout` callback
Reviewed By: javache
Differential Revision: D43466967
fbshipit-source-id: 7a1ce717e7d5cc96a58b8d3ad9def6cf6250871f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36236
D38198351 (https://github.com/facebook/react-native/commit/d574ea3526e713eae2c6e20c7a68fa66ff4ad7d2) addedd a guard to FlatList, to no-op if passed `data` that was not an array. This broke functionality where Realm had documented using `Realm.Results` with FlatList. `Real.Results` is an array-like JSI object, but not actually an array, and fails any `Array.isArray()` checks.
This change loosens the FlatList contract, to explicitly allow array-like non-array entities. The requirement align to Flow `ArrayLike`, which allows both arrays, and objects which provide a length and indexer. Flow `$ArrayLike` currently also requires an iterator, but this is seemingly a mistake in the type definition, and not enforced.
Though `Realm.Results` has all the methods of TS `ReadonlyArray`, RN has generally assumes its array inputs will pass `Array.isArray()`. This includes any array props still being checked [via prop-types](https://github.com/facebook/prop-types/blob/044efd7a108556c7660f6b62092756666e39d74b/factoryWithTypeCheckers.js#L548).
This change intentionally does not yet change the parameter type of `getItemLayout()`, which is already too loose (allowing mutable arrays). Changing this is a breaking change, that would be disruptive to backport, so we separate it into a different commit that will be landed as part of 0.72 (see next diff in the stack).
Changelog:
[General][Changed] - Make FlatList permissive of ArrayLike data
Reviewed By: yungsters
Differential Revision: D43465654
fbshipit-source-id: 3ed8c76c15da680560d7639b7cc43272f3e46ac3
Summary:
changelog: [internal]
Move initialisation to `init` function. This allows subclasses of `RCTAppDelegate` to use new architecture when overriding `didFinishLaunchingWithOptions`
Reviewed By: cipolleschi
Differential Revision: D43535602
fbshipit-source-id: 32adb5416e67a63ad168f0ed2480287bf178a6a6
Summary:
After reviewing the doc [`Image`](https://reactnative.dev/docs/image), the typescript compiler doesn't know the following properties:
- src
- srcSet
- referrerPolicy
- tintColor
- objectFit
But after reviewing the source code and this [`commit`](https://github.com/facebook/react-native/commit/b2452ab216e28e004dc625dd8e1ad32351a79be9), the `objectFit` property isn't one related to the Image component but to the `style` props, making the official doc outdated. So, an [`issue in the react-native-website repo`](https://github.com/facebook/react-native-website/issues/3579) have been created and I decided to not include the objectFit prop in this PR.
So, this PR includes those properties: sec, secSet, referrerPolicy and tintColor
## Changelog
[GENERAL][FIXED] Add src, srcSet, referrerPolicy, tintColor to Image.d.ts declaration file
Pull Request resolved: https://github.com/facebook/react-native/pull/36214
Reviewed By: NickGerleman
Differential Revision: D43437894
Pulled By: rshest
fbshipit-source-id: 497426490134aba0a474c49bf8bab9131f2e5845
Summary:
[Changelog][Internal]
This adds a method, `emitDeviceEvent` to the C++ API of TurboModules, which allows to make calls to JS's `RCTDeviceEventEmitter.emit` from a C++ TurboModules.
This is a very common pattern, specifically for the VR apps, but not only for them - e.g. Desktop fork also has a [custom implementation for this](https://www.internalfb.com/code/fbsource/third-party/microsoft-fork-of-react-native/react-native-utils/RCTEventEmitter.cpp).
Note that my original intent was to actually backport the latter, however there are some complications with wiring things in a robust way, without exposing too much stuff and relying on singletons or folly::dynamic.
So I ended up adding it to the TurboModule API itself and use the scheduler/JSI facilities instead.
This approach is arguably well self-contained, uses high level APIs, and shouldn't be abusable much.
Since I was trying to avoid usage of folly::dynamic in this case, I used a kind of "value factory" pattern instead in order to send the arguments to the JS thread in a thread safe way (see [the discussion here](https://fb.workplace.com/groups/rn.fabric/permalink/1398711453593610/)).
Reviewed By: christophpurrer
Differential Revision: D43466326
fbshipit-source-id: a3cb8359d08a46421559edd0f854772863cb5c39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36209
ThisChange automatically enable the RuntimeScheduler when the new architecture is enabled, both on RNester and in the Template app.
Note that no migration steps are required.
## Changelog
[iOS][Changed] - Automatically install the RuntimeScheduler
Reviewed By: sammy-SC
Differential Revision: D43392059
fbshipit-source-id: 609ded9bdc3db13a0d54ff44d0d4687dfc8617a5
Summary:
By leveraging the `PUBLIC_HEADERS_FOLDER_PATH` build settings of Xcode, we can instruct cocoapods to generate the frameworks Headers in a specific folder, for example the `React` folder.
This allows us to maintain the `#include`/`#import` structure, even if the framework has a different name.
However, we need to update the search paths to take into account this extra folder.
## Changelog:
[iOS][Changed] - Generate RCTFabric framework's headers in the React folder
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43425677
fbshipit-source-id: 94a4f3a3c7de86341b3ce3457704e6b8fb9a588e
Summary:
Update podspecs with the right search paths to include the required framework by every module.
## Changelog:
[iOS][Changed] - Update search paths to support `use_frameworks!` with Fabric
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089372
fbshipit-source-id: 4bbfc4b98bd289d66ce4015429d581856d9c05b3
Summary:
This change solve a Circular Dependency where
- `React-Core` depends on `ReactCommon` because `RCTAppSetupUtils.h` (in Core) imports the `RCTTurboModuleManager` (from ReactCommon)
- `RCTTurboModuleManager` in `ReactCommon` depends on `React-Core` because it imports several classes from it (e.g. the `RCTBridge` class)
## Changelog:
[iOS][Breaking] - Moved the RCTAppSetupUtils to the AppDelegate library to break a dependency cycle
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089183
fbshipit-source-id: d7fc36a50811962caf7cff77bb45d42b8cdd4575
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36215
When we introduced the RCTAppDelegate library, we prepared some template methods for the user to customise their views.
However, after they customized their view, we were chaing the background color to match the system background. This would actually override the background color they set in their own customisation step.
This change make sure that we set the background color before they apply their customisations. In this way, we set the background color and, if they want, they can change it and that changw would be honoured.
This change also fixes [this issue](https://github.com/facebook/react-native/issues/35937)
## Changelog
[iOS][Fixed] - Honour background color customisation in RCTAppDelegate
Reviewed By: cortinico
Differential Revision: D43435946
fbshipit-source-id: cdbdbd5b07082ae7843a4dab352dd1195c69e036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36197
[Changelog][Internal]
This turns NativePerformance* module dependencies into "TurboModule plugins", which allows for more streamlined client integration (as it makes them register automatically once the dependency is there).
Reviewed By: rubennorte
Differential Revision: D43353204
fbshipit-source-id: 01d0089750a4873088dc4aefe34fd48693ee9791
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36152
[Changelog][Internal]
By [the W3C standard](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), `PerformanceObserver.observer` can optionally take a `durationThreshold` option, so that only entries with duration larger than the threshold are reported.
This diff adds support for this on the RN side, as well as unit tests for this feature on the JS side.
NOTE: The standard suggests that default value for this is 104s. I left it at 0 for now, as for the RN use cases t may be to too high (needs discussion).
Reviewed By: rubennorte
Differential Revision: D43154319
fbshipit-source-id: 0f9d435506f48d8e8521e408211347e8391d22fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36181
[Changelog][Internal]
Implements EventCounts API (`Performance.eventCounts`) for Web Performance, according to the W3C standard, see the specs here: https://www.w3.org/TR/event-timing/#eventcounts
The rationale for why we need it is to support some advanced metrics computations, such as a ratio of "slow events" to total event count, per event type.
Reviewed By: rubennorte
Differential Revision: D43285073
fbshipit-source-id: 2c53d04d9a57c1301e37f2a5879072c8d33efbbf
Summary:
This diff adds new performance API `memory`, which is a read-only property that gets the current JS heap size from native side.
Note that the JSI API returns an unordered map with unknown list of memory information, which is different from the [web spec](https://fburl.com/p0vpbt33). We may enforce specific memory info type on the JSI API so that it can be properly translate to the web spec.
- Update the JS spec
- Update Native implementation and return memory information with JSI API `jsi::instrumentation()::getHeapInfo()`
- Add native performance module to catalyst package
Changelog:
[General][Added] - Add performance memory API with native memory Info
Reviewed By: rubennorte
Differential Revision: D43137071
fbshipit-source-id: 319f1a6ba78fce61e665b00849ecf2579094af83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36116
[Changelog][Internal]
Add a minimal/reference JavaScript implementation for NativePerformanceObserver - the purpose is both unit testing (JS and native sides separately) and potentially shimming the part of functionality that is not dependent on native side.
This is both a setup for adding general unit tests for the Performance* APIs, but also to be able to do non-trivial changes on JS side for WebPerformance (such as in (D43154319).
Reviewed By: rubennorte
Differential Revision: D43167392
fbshipit-source-id: 213d9534d810dece1dd464f910e92e08dbf39508
Summary:
This diff adds `TraceUpdateOverlay` native component to RN `AppContainer.js`. This will enable the overlay when the build is in DEV environment and the DevTools global hook exists. It also closed gap between the JS dev mode and native dev support flag, so that the native component will be available when used by JS.
## Update (2/13/2023)
Instead of the original approach where I put a default value to the devsupport manager flag, I did ui manager check from JS and make sure the native component exists before using it. This is cleaner.
## Problem
Since the `AppContainer` is being used by all RN apps, we need to make sure the native component is registered in UI Manager of the RN app when it's used. Currently, the native component lives in the `DebugCorePackage.java`, which is added to the RN app [when the `DevSupportManager` is used](https://fburl.com/code/muqmqbsa). However, there's no way to tell if an app is using dev support manager in JS, hence there are gaps when the JS code uses `TraceUpdateOverlay`, vs when the native code registered the native component. This issue caused test error in [ReactNativePerfTest](https://fburl.com/testinfra/j24wzh46) from the [previous diff](https://fburl.com/diff/bv9ckhm7), and it actually prevents Flipper from running this properly as shown in this video:
https://pxl.cl/2sqKf
The errors shown in Flipper indicates the RN surface from the plugin is also missing `TraceUpdateOverlay` in its UI Manager:
{F869168865}
## Solution
To fix this issue, we should find a way to expose if the app is using dev support manager in JS. Or we should set to use DevSupportManager whenever it's a dev build as claimed in JS. I will try to find some way to achieve either one of this. I am open to suggestions here for where I should add the native component to. Given that it's used in the AppContainer, and any app could be built in development mode, I don't want to make people to manually add this native component themselves.
## Alternatives
There are some other approaches that could mitigate the issue, but less ideal:
For the test issue
1) Add `setUseDeveloperSupport(true)` to [ReactNativeTestRule.java](https://fburl.com/code/7jaoamdp). That will make the related test pass by using the DevSupportPackages, which has the native component. However, it only fixes tests using that class.
2) Override the package for [ReactNativeTestRule.java](https://fburl.com/code/b4em32fa), or `addPackage` with more packages including the native component. Again this only fixes this test.
3) Add the native component to the [`MainReactPackage`](https://fburl.com/code/nlayho86), which is what I did here in this diff. This would fix more cases as this package is [recommended to be used](https://fburl.com/code/53eweuoh) for all RN app. However, it may not fix all the cases if the RN app didn't manually use it.
4) Add the native component in the [`CoreModulesPackage`](https://fburl.com/code/lfeklztl), which will make all RN apps work, but at the cost of increase package size when this feature is not needed. Or, we could argue that we want to have highlights on trace updates for production build as well?
Changelog:
[Internal] - Enable TraceUpdateOverlay to RN AppContainer
Reviewed By: rubennorte
Differential Revision: D43180893
fbshipit-source-id: a1530cc6e2a9d8c905bdfe5d622d85c4712266f8
Summary:
This diff adds `TraceUpdateOverlay` native component to render highlights when trace update is detected from React JS. This allows a highlight border to be rendered outside of the component with re-renders.
- Created `TraceUpdateOverlay` native component and added to the `DebugCorePackage`
- Added to C++ registry so it's compatible with Fabric
- Added to `AppContainer` for all RN apps when global devtools hook is available
Changelog:
[Android][Internal] - Add trace update overlay to show re-render highlights
Reviewed By: javache
Differential Revision: D42831719
fbshipit-source-id: 30c2e24859a316c27700270087a0d7779d7ad8ed
Summary:
[Changelog][Internal]
`NativePerformanceObserver` TurboModule API would get the type for performance entries as strings in one direction (`start/stopReporting`) and as integers in another direction (inside `RawPerformanceEntry`, for optimization on the native side).
This makes is symmetrical and consistent, all the conversions are now handled on the JS side.
Reviewed By: christophpurrer
Differential Revision: D43236466
fbshipit-source-id: 08e1b62df90e6d26a11577d6b6b1d91a6bce8339
Summary:
When working on Dynamic Type, I accidentally referred to it as "Dynamic Text" in some of the documentation. This is just a minor cleanup bit.
## Changelog
[IOS] [FIXED] - Fix typo in documentation
Pull Request resolved: https://github.com/facebook/react-native/pull/36113
Test Plan: Non-functional change, no testing should be needed :-)
Reviewed By: javache
Differential Revision: D43184999
Pulled By: cortinico
fbshipit-source-id: ed057e48289ae6037637bacecb20b8dd58c1d8b5
Summary:
I encountered build error when using performance API in catalyst android mobile app. The error message P617433618 points at using non-const `std::strlen` API in a `constexpr`.
```
$ buck install catalyst-android
...
stderr: xplat/js/react-native-github/Libraries/WebPerformance/PerformanceEntryReporter.cpp:208:13: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr]
constexpr StrKey(const char *s)
^
xplat/js/react-native-github/Libraries/WebPerformance/PerformanceEntryReporter.cpp:209:39: note: non-constexpr function 'strlen' cannot be used in a constant expression
: key(folly::hash::fnv32_buf(s, std::strlen(s))) {}
```
Changelog:
[General][Fixed] - Fixed string key calculation in constexpr from Performance C++ native module.
Reviewed By: javache
Differential Revision: D43136624
fbshipit-source-id: c691671b157b507745c67a505c91f75cf6b878d1
Summary:
This adds the `DOMRect` and `DOMRectReadOnly` classes to React Native, mostly following the Web spec.
This is a requirement for `node.getBoundingClientRect()`, which we'll implement in React (in https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactFabricHostConfig.js#L134-L323).
Changelog: [General][Added] - Added Web-compatible `DOMRect` and `DOMRectReadOnly` classes to the global scope.
Reviewed By: ryancat
Differential Revision: D42963222
fbshipit-source-id: bf2ed15bfbfd71822cb6f969f8cc0a67c7834333
Summary:
This declares a few globals that were missing in our `global.js` Flow declaration file:
* `process`
* `performance` with its current definition. We'll replace it with the new API when we replace `setupPerformance` with `setupWebPerformance`.
* `navigator`
* `setImmediate`
* `clearImmediate`
Eventually we should stop including all DOM definitions that Flow provides out of the box and define only what we provide (which is pretty much this file).
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42964772
fbshipit-source-id: 6156968e8a9d193e7068d8a5043aa682ad45bba1
Summary:
This test is flaky on Windows only on CI, so I'm disabling it as we cover this
test already on other platforms.
Changelog:
[Internal] [Changed] - Disable a /Libraries/Pressability test on Windows only
Reviewed By: yungsters
Differential Revision: D43153475
fbshipit-source-id: 861a31fbbf3c14f2af95ca3ffd40737ef975048b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36106
Having `concurrentRoot` disabled when Fabric is enabled is not recommended.
This simplifies the setup and makes sure that both are either enabled or disabled.
## Changelog:
[iOS] [Breaking] - Hardcode concurrentRootEnabled to `true` when Fabric is enabled
Reviewed By: cortinico
Differential Revision: D43153402
fbshipit-source-id: d67aeb3413dbdf2430381aa44ede47ed00db32c6
Summary:
Incorrect TS type disallows use of `hitSlop={number}`. Fixed by using Pressable's hitSlop type.
NOTE: I did not bother to change Flow types in the `.js` file, please add a commit doing that if required.
## Changelog
[GENERAL] [FIXED] - Fix touchable hitSlop type
Pull Request resolved: https://github.com/facebook/react-native/pull/36065
Test Plan: None needed
Reviewed By: christophpurrer
Differential Revision: D43117689
Pulled By: javache
fbshipit-source-id: 96e5ae650f47382c8d7fa1ddf63c76461c65dcc7
Ruslan Shestopalyuk
fabriziobertoglio1987
Jerry
Steve Alves-Blyt
Luna Wei
Birkir Gudjonsson
Nick Gerleman
Harshika
Samuel Susla
Xin Chen
Riccardo Cipolleschi
Pieter Vanderwerff
Adam Gleitman
Rubén Norte
Nicola Corti
bigcupcoffee
