Summary:
The documentation for `useColorScheme()` suggested that the user's preferred color scheme will be 'Dark Mode'. Instead suggesting 'Dark Mode' as an example of what the user's preferred color scheme could be is more correct.
## Changelog
[INTERNAL] [FIXED] - Edited documentation for `useColorScheme()` hook
Edited
```javascript
/**
* A new useColorScheme hook is provided as the preferred way of accessing
* the user's preferred color scheme (aka Dark Mode).
*/
export function useColorScheme(): ColorSchemeName;
```
to
```javascript
/**
* A new useColorScheme hook is provided as the preferred way of accessing
* the user's preferred color scheme (e.g. Dark Mode).
*/
export function useColorScheme(): ColorSchemeName;
```
Pull Request resolved: https://github.com/facebook/react-native/pull/35141
Test Plan: Documentation only - no testing required.
Reviewed By: cipolleschi
Differential Revision: D40934781
Pulled By: rshest
fbshipit-source-id: acac8947c3f99016839be27f505066e8992a20fa
Summary:
We are running into a group seeing frequent disconnects from Metro in a specific office. These are surfaced (at least on iOS) as websocket closures, without a prior websocket error. WebSocket closure can be for a variety of reasons, and the spec for a CloseEvent is to include fields `wasClean`, `code`, and `reason`, with `code` having the most well-defined meaning.
This change makes it so that we emit extra context when the websocket is closed. That should help inform developers the reason behind any close that may be abnormal.
Changelog:
[General][Added] - Log Abnormal Closes to Metro Websocket
Reviewed By: motiz88
Differential Revision: D40660765
fbshipit-source-id: ef606d8d809af1c697a78eb00cc5666c29a8bca3
Summary:
As pointed out by necolas on https://github.com/facebook/react-native/issues/34424#issuecomment-1261482517 we forgot we add the `role` prop mapping to the `Text` component. This PR adds a new `role` prop to `Text`, mapping the web `role` values to the already existing `accessibilityRole` prop and moves the `roleToAccessibilityRoleMapping` to a common file that can be imported by both the `Text` and `View` components as requested on https://github.com/facebook/react-native/issues/34424. This PR also updates the RNTester AcessebilityExample to include a test using this new prop.
## Changelog
[General] [Added] - Add role prop to Text component
Pull Request resolved: https://github.com/facebook/react-native/pull/34976
Test Plan:
1. Open the RNTester app and navigate to the Accessibility Example page
2. Test the `role` prop through the `Text with role = heading` section
Reviewed By: yungsters
Differential Revision: D40596039
Pulled By: jacdebug
fbshipit-source-id: f72f02e8bd32169423ea517ad18b598b52257b17
Summary:
This diff adds explicit type arguments to polymorphic function calls that do not constrain their types. This codemod will reduce the error burden that will come in a future version of flow.
This specific diff was generated by running:
```
flow codemod annotate-implicit-instantiations --write .
flow --json --pretty | jq '.errors | .[] | .message | .[] | .loc |.source' | sort | uniq | sed -e 's/"//g' | xargs hg revert
hg st -n | xargs grep "generated" | sed -e 's/:.*//g' | xargs hg revert
arc f
```
So these are the codemod results that introduced no new errors and no generated files.
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D40413074
fbshipit-source-id: 42b52719978f1098169662b503dbcfd8cefdad53
Summary:
There's no need for the 3 type arguments here. Flow will infer a union already if multiple properties are provided. Worse, by not providing these properties these tvars end up with no bounds, which can cause downstream constraints to stall. All of the suppresisons added here are for legitimate errors that were uncovered by consolidating to one type argument.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D40355811
fbshipit-source-id: 088fd087017a6082c793ef00c8810a81b39fb9fb
Summary:
There's no need for the 3 type arguments here. Flow will infer a union already if multiple properties are provided. Worse, by not providing these properties these tvars end up with no bounds, which can cause downstream constraints to stall. All of the suppresisons added here are for legitimate errors that were uncovered by consolidating to one type argument.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D40355813
fbshipit-source-id: f02a101e5e32f3a2f660a34349e6416b9fde4124
Summary:
`VirtualizedList_EXPERIMENTAL` is a fork of VirtualizedList. It was originally created for the purpose of keyboard/a11y fixes, which required the list to allow rendering discontiguous regions of cells. So, the large part of the refactor is in the data structure used to represent state (now a sparse bitmask), and building out the render function to operate off the bitmask.
This structure allows pre-rendering areas where we know focus must be able to be synchronously be moved to. This is exercised on platforms like Windows and macOS which fire view level focus events. The new implementation otherwise aims to preserve near-exact list behavior as previously.
Apart from the structure change, the refactor has made the code (subjectively) a lot easier to reason about, and there are now stronger internal invariants than before. The bitmask structure also enables new approaches for nested list stability, and implementing OffScreen.
**Why ship it now?**
Having two implementations has multiple times prevented other changes to VirtualizedList, so it is incurring a constant engineer cost.
At this point, we have a lot of reason to be confident in the maturity of the new list implementation (see the test plan below). So, reconciling the implementations not only unlocks the enhancements of the new list, but unblocks future changes to VirtualizedList.
## Test Plan
1. **Unit tests:** A few dozen unit tests were added to VirtualizedList, validating the regions it renders in response to injected input, across its API surface. Both VirtualizedList implementations must pass the same tests, around expected behavior.
2. **RNTester:** Scenarios in RNTester were manually validated, and all worked as before
3. **New invariants:** I added a lot of internal logic checks and bounds checks as invariant violations, to try to produce signal if any part of the refactor went unexpected in the wild.
4. **MSFT Rollout:** I rolled out the changes as a fork of VirtualizedList at MSFT to a couple of high-usage surfaces using Android, iOS, and Windows on Paper. Some invariant violations were surfaced and fixed, but telemetry showed solid system and scenario health with the change.
5. **Meta import:** Fixed all land-blocking test failures when using the new list. These were confined to updating snapshots, and adding additional checks for invalid input.
6. **Panel apps:** Manually validated top-level surfaces of panel apps in debug/release modes. Fixed a couple of invariant violations and novel usages. Profiled new JS structures against an expensive list with Hermes profiler.
7. **Facebook App Rollout:** After some manual validation of top-level surfaces, the change was rolled out to Facebook for Android and iOS as an experiment. New invariant violations were fixed, and the change has sat in production for several weeks at this point, while measuring impact to metrics like error rate, responsiveness, and impressions.
This is the first introduction to all of OSS, and some Meta internal apps. This means there may still be novel usages of VirtualizedList that were not picked up during testing, but I think there has been enough diligence to roll out what has been tested, and forward fix anything unexpected that might still come up.
Changelog:
[General][Changed] - Ship VirtualizedList_EXPERIMENTAL
Reviewed By: javache
Differential Revision: D40259791
fbshipit-source-id: 63eee9381d197a1e38ae663b2158436ff135c0e1
Summary:
Add explicit annotations to useCallback as required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Codemod command: `flow codemod annotate-use-callback`
drop-conflicts
bypass-lint
Changelog: [Internal]
Reviewed By: evanyeung
Differential Revision: D40079418
fbshipit-source-id: 59750a5d07b2ac1f440927794a7523682f048a5e
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.
I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.
The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.
Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files
Reviewed By: lunaleaps, rshest
Differential Revision: D39796598
fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
Summary:
Changelog: [internal]
This replaces all direct references to the `ReactNative` module (which is the Paper renderer) to `RendererProxy` which would select between Paper and Fabric correctly.
The implementation of these functions is exactly the same right now.
As per the removal of the fix for T55744311 in `ScrollView`, I verified this doesn't cause any issues in the screen where it failed before.
Reviewed By: javache
Differential Revision: D39270691
fbshipit-source-id: 03882748fe4b754b9a2c5e9d4c4f003b94ed49ef
Summary:
The `JSDevSupport` module is incompatible with Fabric. Given it's not used internally and it's undocumented in OSS, we decided to remove it altogether.
Changelog: [Internal]
Reviewed By: javache, nlutsenko
Differential Revision: D39305892
fbshipit-source-id: 82455701a0b9ba83e6f971fc774280dceb2b22e0
Summary:
I've noticed that `BackHandler.removeEventListener()` performs two same `indexOf()` calls on an array that is not changing. By removing extra `indexOf` we can slightly improve time complexity of `BackHandler.removeEventListener()` from O(2n) to O(n)
## 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] [Fixed] - Remove extra indexOf call in BackHandler.removeEventListener
Pull Request resolved: https://github.com/facebook/react-native/pull/34281
Test Plan:
1. Add the following code to any function component
```javascript
BackHandler.addEventListener('hardwareBackPress', () => true).remove();
```
2. Press on hardware back button
Expected result: Application closes
Reviewed By: dmitryrykun
Differential Revision: D38198510
Pulled By: javache
fbshipit-source-id: eab6a57689a536623138a4b3ebddbf9ba87d281f
Summary:
Now that [exact_empty_objects has been enabled](https://fb.workplace.com/groups/flowlang/posts/1092665251339137), we can codemod `{...null}` to `{}` - they are now equivalent.
1) Run my one-off jscodeshift codemod
2) `scripts/flow/tool update-suppressions .` (as some suppressions move around due to the change)
drop-conflicts
Reviewed By: bradzacher
Differential Revision: D37834078
fbshipit-source-id: 6bf4913910e5597e5dd9d5161cd35deece6a7581
Summary:
Removes the `isTVOS` check, which just duplicated and returned the `isTV` check anyway.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Removed] - Remove deprecated `isTVOS` constant.
Pull Request resolved: https://github.com/facebook/react-native/pull/34071
Test Plan: Run against CI, and apply changes as needed.
Reviewed By: cipolleschi
Differential Revision: D37434978
Pulled By: cortinico
fbshipit-source-id: 2b38253125251b0ce28cf10c88471d8f16704999
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
With the new architecture, this module should be using the implementation from ReactFabric instead. However, given the ReactNative module had side effects (like registering `RCTEventEmitter`), let's import from ReactFabric only in the latest "new architecture" mode.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D36535626
fbshipit-source-id: 6758b671df9a47607d8caf4a021ac73410f4c6e9
Summary:
We are currently seeing warning `Native Component 'X' that calls codegenNativeComponent was not code generated at build time. Please check its definition.` even though we have not opted into Fabric. This warning is not actionable and is just noisy.
See also discussion: https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2657180
## Changelog
[General] [Fixed] - Remove unactionable warning about `codegenNativeComponent` when on 'Paper'
Pull Request resolved: https://github.com/facebook/react-native/pull/33830
Test Plan: n/a
Reviewed By: dmitryrykun
Differential Revision: D36377844
Pulled By: cortinico
fbshipit-source-id: 23c9f9dbf0ce1cea60c5dc8caa02d0dc53bd635d
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Some manual fixes, in particular to React Native code, which is used and can be synced to other repos (e.g. WWW).
With these changes, error diff in Xplat is down to ~1990 errors
Note that after I roll out `exact_empty_objects`, I'll codemod all the `{...null}` (the only way to get an exact empty object currently) back to `{}`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D36142838
fbshipit-source-id: 054caf370db230f42a4c5f5706c88979ef246537
Summary:
Remove old deprecated modules that cause annoying warnings. This can be a breaking change for some third-party modules.
## Changelog
[General] [Removed] - Remove deprecated removeListener methods
Pull Request resolved: https://github.com/facebook/react-native/pull/33580
Test Plan: See `flow-check` and `build-arvr-js-flow` succeed in Sandcastle.
Reviewed By: cortinico
Differential Revision: D35549719
Pulled By: yungsters
fbshipit-source-id: 0495e36de19db434362d5de56463d9c1ad6edd73
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Making this change exposes a variety of errors. We can prevent these errors by annotating what we want the type of the empty object to be.
Reduces Xplat error diff to 2.3k
- Announcement: [post](https://fb.workplace.com/groups/flowlang/posts/903386663600331)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
Format:
```
arc f
```
Sort imports
```
hg l -n | xargs js1 lint --fix --rule 'fb-tools/sort-requires'
```
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D36086696
fbshipit-source-id: 90447279f2e6e38f44189b74ec0297719f7adf58
Summary:
Annotations inside of destructuring (e.g. `const [foo: number] = ...`) are invalid Flow syntax. We currently ignore them, and in the future will error on them (D35304565).
Remove them using the codemod from D35390352
Locally changed WWW_ROOT, FLOW_ROOTS, and excluded paths in scripts/typedjs/flow/runner.config.js (e.g. P492224584) - and then
```
scripts/typedjs/flow/runner codemod removeAnnotationsInDestructuring ~/fbsource/xplat/js
```
formatting files didn't work, so do it manually
Changelog: [Internal]
drop-conflicts
Reviewed By: fred2028
Differential Revision: D35419146
fbshipit-source-id: e4c05506ceec11afcc8e92f13f732510ebabdbc3
Summary:
## Rationale
verifyComponentAttributeEquivalence is the legacy check for making sure that Static ViewConfigs match Native ViewConfigs. Eventually, we should just delete this module/check from the codebase.
## Changes
This diff migrates the RNHostComponentViewConfig differences screen to display the ViewConfig differences using the new StaticViewConfigValidator validation result vs the legacy validator's lefthandObjectDiff method.
## Benefits:
- Now, **all the diffing logic** on this route uses the new StaticViewConfigValidator.
- This takes us one step closer towards deleting verifyComponentAttributeEquivalence
- StaticViewConfigValidator [supports ignoring ViewConfig properties](https://fburl.com/code/2it5r7py). Now, the RNHostComponentViewConfig respects these ignores.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34017602
fbshipit-source-id: 3ad909adcbb95b932a269dd55dd5445834a9cfd4
Summary:
## Impact
Fix the Static ViewConfig for <View/>.
This diff fixes the base ViewConfig for all HostComponents on both platforms. Consequently, it simplifies SVC reconciliation efforts, by nearly eliminating the first of these classes of SVC errors:
1. Unexpected properties in SVC
2. Missing properties in SVC
3. Not matching properites in SVC
## What is the base ViewConfig on each iOS/Android?
**On iOS:**
- All props come from ViewManagers
- All HostComponent ViewManagers extend <View/> ViewManager
https://pxl.cl/1SxdF
Therefore, the base ViewConfig for all components should be <View/>'s static ViewConfig.
**On Android:**
The component model is a bit more complicated:
https://pxl.cl/1Vmp5
Takeaways:
- Props come from Shadow Nodes **and** ViewManagers
- Nearly all HostComponent ViewManagers extend BaseViewManager. But, that's not <View/>'s ViewManager.
- <View/>'s ViewManager is [ReactViewManager](https://fburl.com/code/0zalv8zk), which is a descendent of BaseViewManager, and declares its own ReactProps.
So, on Android, it's not safe for the base ViewConfig to be <View>'s ViewConfig:
1. No components actualy incorportate <View/>'s props
2. Some components don't even incorporate BaseViewManager's props.
So, what should the base ViewConfig be on Android?
- Nearly all components extend BaseViewManager. BaseViewManager must have a shadow node [that extends LayoutShadowNode](https://www.internalfb.com/code/fbsource/[47d68ebc06e64d97da9d069f1ab662b392f0df8a]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/uimanager/BaseViewManager.java?lines=40). Therefore, we'll make the base ViewConfig on Android be generated by BaseViewManager + LayoutShadowNode.
## Changes
In this diff, I removed ReactNativeViewViewConfig, and introduced a new view config called PlatformBaseViewConfig. This ViewConfig partial will capture all the props available on all HostComponents on **both** platforms. This may not necessarily be the props made available on <View/>.
The only components that don't extend the base platform props are: RCTTextInlineImage. What we do with these components is TBD.
Changelog: [Internal]
Reviewed By: p-sun, yungsters
Differential Revision: D33135055
fbshipit-source-id: 7299f60ae45ed499ce47c0d0a6309a047bff90bb
Summary:
## iOS
On iOS:
- All props come from ViewManagers
- All HostComponent ViewManagers extend <View/> ViewManager
https://pxl.cl/1SxdF
Therefore, it's safe to have all HostComponent Static View Configs extend <View/> Static View Config.
## Android
On Android, the model is a bit more complicated:
https://pxl.cl/1Vmp5
Takeaways:
- Props come from Shadow Nodes **and** ViewManagers
- Nearly all HostComponent ViewManagers extend BaseViewManager. But, that's not <View/>'s ViewManager.
- <View/>'s ViewManager is [ReactViewManager](https://fburl.com/code/0zalv8zk), which is a descendent of BaseViewManager, and declares its own ReactProps.
So, it's not safe to have all Android HostComponent Static View Configs to extend <View/>'s Static View Config:
1. No components actualy incorportate <View/>'s props
2. Some components don't even incorporate BaseViewManager's props.
## Changes
In this diff, I removed ReactNativeViewViewConfig, and introduced a new view config called PlatformBaseViewConfig. This ViewConfig partial will capture all the props available on all HostComponents on **both** platforms. This may not necessarily be the props made available on <View/>.
The only components that don't extend the base platform props are: RCTTextInlineImage. What we do with these components is TBD.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32187832
fbshipit-source-id: 9a057abb3f58801615891c21e42ad4cfa5c69f21
William Sawyer
Gabriel Donadel Dall'Agnol
George Zahariev
Nick Gerleman
Sam Zhou
Jordan Brown
Tim Yung
Evan Yeung
Luna Wei
Nick Gerleman
Rujin Cao
Marshall Roch
Rubén Norte
Pieter Vanderwerff
Vitalii T
George Zahariev
Zachinquarantine
Pieter De Baets
Kevin Gozali
Tommy Nguyen
Sam Zhou
Rick Hanlon
Matin Zadeh Dolatabad
Paige Sun
Ramanpreet Nara
Andres Suarez
Gijs Weterings