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:#️⃣: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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36092
This test is partially disabled already, causing high flakyness of the `test_windows` CI job.
I'm taking a different approach at disabling it here (disabling the offending tests using a `Promise`
rather than disabling at the assert level).
Changelog:
[Internal] [Changed] - Reduce flakyness on InteractionManager-test
Reviewed By: cipolleschi
Differential Revision: D43120897
fbshipit-source-id: 69edee804aaaa8b6f89ff8440561254f393efae4
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)
## Changelog
[GENERAL] [ADDED] - Added `setColorScheme` to `Appearance` module
Pull Request resolved: https://github.com/facebook/react-native/pull/35989
Test Plan:
This is a void function so testing is rather limited.
```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`
```
Reviewed By: NickGerleman
Differential Revision: D42801094
Pulled By: jacdebug
fbshipit-source-id: ede810fe9ee98f313fd3fbbb16b60c84ef8c7204
Summary:
This change re-applies D41745930 (2e3dbe9c2f) (and D42805202 (1479b2ac26) which was also partially reverted), re-registers additions as moves, then applies D43063551 which has been added to the changes since migration.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D43068114
fbshipit-source-id: 72997700bf9962d82a988599481e255b69e68a9b
Summary:
This change reverts D41745930 (2e3dbe9c2f) as part of a stack to splice back source history which was lost (Git registered the file moves as additions).
It is expected this diff will individually fail. The entire stack should be applied at once.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D43068113
fbshipit-source-id: c8398629fe5dcc1ca4bf02f550adc00c78a8487a
Summary:
Since currently the check was for null , and that too not === check. So added a check , only for item !== undefined, since null is an assigned value, and we can have null as values in the array for flatlist,
undefined is in absence of any data, hence if its only undefined we should assign falsy to frame variable, since null is an assigned value, sometimes null can be passed to data in the dataset
Hence added a check on top of Sam's previous commit to fix it
UPDATE:
Now after discussing with NickGerleman , removed the check for item with nullish/undefined.
Now directly frames value is being controlled by _keyExtractor function
This is already an issue [https://github.com/facebook/react-native/issues/35280](url)
Currently in my project, even [0,1] -> didnt trigger onViewableItemsChanged since, it was considered as falsy value,
went to check the node modules code for flatlist, debugged this.
When pulled latest main branch, saw it was partially fixed , but for null as values it wasnt fixed. So added that check .
## Changelog
[General] [Fixed] Fix VirtualizedList onViewableItemsChanged won't trigger if first item in data is null
```
const frame =
item !== undefined ? this._frames[this._keyExtractor(item, index, props)]
: undefined;
```
in place of existing which is
```
const frame =
item != null ? this._frames[this._keyExtractor(item, index, props)]
: undefined;
```
Update:
`const frame = this._frames[this._keyExtractor(item, index, props)]`
Finally this is the one used for getting frames value
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/36009
Test Plan:
Checked out in my local , wrt changes , will share video if required
Update:
After the new changes too, checked in local, working fine
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Reviewed By: NickGerleman
Differential Revision: D42934757
Pulled By: skinsshark
fbshipit-source-id: cb5622a79523bccbdfbc15470baf84422f635b33
Summary:
I discovered that 0.69 could run React Native as Dynamic framework with Hermes and starting from 0.70 that's not possible anymore.
This diff restore that possibility.
Notice that now Hermes provisdes JSI and Dynamic Frameworks requires that all the dependencies are explicitly defined, therefore, whenever we have a pod that depended on `React-jsi`, now it also has to explicitly depends on `hermes-engine`
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the Old Architecture with Hermes
Reviewed By: cortinico
Differential Revision: D42829728
fbshipit-source-id: a660e3b1e346ec6cf3ceb8771dd8bceb0dbcb13a
Summary:
Bringing the typescript function signature in-line with the js code.
## Changelog
[GENERAL] [FIXED] - Added AlertOptions argument to the type definition for Alert.prompt to bring it into parity with the js code.
<!-- 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/35957
Test Plan: Before the change, VS Code would show a typescript error when I pass AlertOptions to Alert.prompt (even though the js would execute successfully and respect the options I passed. After the change, when I use an Alert.prompt in VS code the function signature was recognized without errors.
Reviewed By: christophpurrer
Differential Revision: D42737818
Pulled By: jacdebug
fbshipit-source-id: 4d4318f38f5c7b7302aae62de5ce224db67e088a
Summary:
This is a [change](https://github.com/microsoft/react-native-macos/pull/1120) we made in our fork (React Native macOS) that we are now upstreaming to reduce the number of diffs between React Native Core and React Native macOS. Also.. one less crash �!
Resolves https://github.com/microsoft/react-native-macos/issues/1679
Original PR notes:
> We've seen a crash downstream where -[NSString stringByReplacingCharactersInRange:withString:] receives a nil value as the replacement string. This is not good, since we expect that argument to be non-null.
>
>We believe that a cause of this is that -[RCTUITextField textView:shouldChangeTextInRange:replacementString:] is being called with nil as the replacement string. (This is legal, as per [Apple's documentation](https://developer.apple.com/documentation/appkit/nstextviewdelegate/1449325-textview?language=objc).) Right now, the only check that this delegate method does is enforcing the maxLength parameter if it exists, and changes in attributes shouldn't affect the length of the string.
## Changelog
[IOS] [FIXED] - `-[RCTUITextField textView:shouldChangeTextInRange:replacementString:]` no longer crashes when we pass in a `nil` replacement string
Pull Request resolved: https://github.com/facebook/react-native/pull/35941
Test Plan: Build should pass. This change has been running in our fork in production for a while so we're fairly confident of it.
Reviewed By: cipolleschi
Differential Revision: D42705382
Pulled By: jacdebug
fbshipit-source-id: 066cd8a4ba134a681f0f4c955594b1fcda61a30e
Summary:
This adds support for `maintainVisibleContentPosition` on Android. The implementation is heavily inspired from iOS, it works by finding the first visible view and its frame before views are update, then adjusting the scroll position once the views are updated.
Most of the logic is abstracted away in MaintainVisibleScrollPositionHelper to be used in both vertical and horizontal scrollview implementations.
Note that this only works for the old architecture, I have a follow up ready to add fabric support.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Add maintainVisibleContentPosition support on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/35049
Test Plan:
Test in RN tester example on Android
https://user-images.githubusercontent.com/2677334/197319855-d81ced33-a80b-495f-a688-4106fc699f3c.mov
Reviewed By: ryancat
Differential Revision: D40642469
Pulled By: skinsshark
fbshipit-source-id: d60f3e2d0613d21af5f150ca0d099beeac6feb91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35888
Changelog:
[Android][Removed] - For supporting Dev Loading View across multiple platforms, changed the Loading View of Android to rely on the native implementation instead of Toast. Getting rid of the JS changes relying on Toast for Dev Loading View now that the native module is released.
Reviewed By: rshest
Differential Revision: D42599220
fbshipit-source-id: ec7098b508c766c07384d48d3bffed075b092b72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35901
[Changelog][Internal]
Partially reverts the change that was redirecting `performance` instance to the new implementation in WebPerformance, until the actual implementation becomes public and native modules are included by default.
Reviewed By: rubennorte
Differential Revision: D42607379
fbshipit-source-id: c1ce995d20b9dfe7aef8436cea00d89b81e32932
Summary:
`accessibilityLabelledBy` is missing from `AccessibilityPropsAndroid` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLabelledBy` TypeScript type
<!-- 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/35883
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604287
Pulled By: NickGerleman
fbshipit-source-id: 476d24d1c0257be787b7e84c2c11bcadc3527979
Summary:
TurboModuleRegistry export functions and not a TurboModuleRegistry object. See https://github.com/facebook/react-native/blob/main/Libraries/TurboModule/TurboModuleRegistry.js#L37
## Changelog
[GENERAL] [FIXED] - Fix TurboModuleRegistry TS type
Pull Request resolved: https://github.com/facebook/react-native/pull/35885
Test Plan:
Tested that the import doesn't generate a type error when used correctly.
```ts
import * as TurboModuleRegistry from 'react-native/Libraries/TurboModule/TurboModuleRegistry';
export default TurboModuleRegistry.get<Spec>('RNCSafeAreaContext');
```
Reviewed By: christophpurrer
Differential Revision: D42604208
Pulled By: NickGerleman
fbshipit-source-id: e6259df24aaf6e37b32cc4b51947294fd655837e
Summary:
`accessibilityLanguage` is missing from `AccessibilityPropsIOS` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLanguage` TypeScript type
<!-- 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/35882
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604363
Pulled By: NickGerleman
fbshipit-source-id: fb8dd4b5bba78a080473a9dc7b49a07587530229
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35875
Fixes https://github.com/facebook/react-native/issues/35871
Nested VirtualizedLists register to their parents for updates, associated to a specfific cellKey set by VirtualizedListCellContextProvider. This cellKey is usually set when rendering a cell for a data item, but we can also render a nested VirtualizedList by putting one in a ListHeaderComponent/ListFooterComponent/ListEmptyComponent.
D6603342 (a010a0cebd) added cellKeys when we render from a header/footer, but not ListEmptyComponent, so that association would silently fail earlier.
D39466677 (010da67bef) added extra invariants to child list handling, that are now triggered by this case, complaining because we are trying to unregister a child list we never successfully registered, due to a missing cellKey.
This fixes the issue by providing a cellKey for ListEmptyComponent as well.
Changelog:
[General][Fixed] - Fix invariant violation when nesting VirtualizedList inside ListEmptyComponent
Reviewed By: christophpurrer
Differential Revision: D42574462
fbshipit-source-id: f76fa795bf471cb8a929c2efdbd814ea51927663