Summary:
While upgrading a project to React 19, I noticed React.ElementRef is deprecated (see [types/react/index.d.ts#L199](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L199)). I think we can replace it for the RN types as well.
Not sure if this is considered as a breaking change.
## Changelog:
[GENERAL] [CHANGED] - TypeScript: Replace deprecated React.ElementRef usages to React.ComponentRef
Pull Request resolved: https://github.com/facebook/react-native/pull/50883
Test Plan:
Create a RNTesterPlayground.tsx next to the normal .js just to validate the type checking is not throwing an unexpected error.
<details>
<summary>Code snippet:</summary>
```tsx
import React, { useRef, useEffect } from 'react';
import { FlatList, Text, View } from 'react-native';
type Item = { id: string; title: string };
const data: Item[] = Array.from({ length: 10 }, (_, i) => ({
id: i.toString(),
title: `Item ${i + 1}`,
}));
const FlatListScrollRefExample: React.FC = () => {
const flatListRef = useRef<FlatList<Item>>(null);
useEffect(() => {
if (flatListRef.current) {
const nativeRef = flatListRef.current.getNativeScrollRef();
console.log('nativeRef', nativeRef?.componentWillUnmount);
}
}, []);
return (
<FlatList
ref={flatListRef}
data={data}
keyExtractor={(item) => item.id}
renderItem={({ item }) => (
<View style={{ padding: 16 }}>
<Text>{item.title}</Text>
</View>
)}
/>
);
};
export default FlatListScrollRefExample;
```
</details>
Reviewed By: cipolleschi
Differential Revision: D73569274
Pulled By: rshest
fbshipit-source-id: f72477b9b3c0eda1007187c7dac3da0433410e86
Summary:
The previous typing of FlatList and VirtualizedList did not convey any information on the type of the items passed in to `onViewableItemsChanged`, but instead the type was set to `any`. This PR adds the type information.
I set a default type `any` for thy ViewToken, because the type is exported and not having it would be a breaking change if that type is used. Like this it gracefully falls back to the default behavior of the `any` type.
Notice: I don't know how typing in "flow" works, but the same "issue" seems to be in there as well. Maybe someone with more flow experience can fix that as well:
https://github.com/facebook/react-native/blob/ae42e0202de2c3db489caf63839fced7b52efc5d/packages/virtualized-lists/Lists/ViewabilityHelper.js#L19-L20
## Changelog:
[GENERAL] [FIXED] - Add type information for items of VirtualizedList in `onViewableItemsChanged` signature
[GENERAL] [FIXED] - Add type information for items of FlatList in `onViewableItemsChanged` signature
Pull Request resolved: https://github.com/facebook/react-native/pull/42773
Test Plan:
Without the changes, typecheck of the project was fine, but with the changes applied to the node_modules/react-native copy a type error was found:
```
$ npm run typecheck
> my-project@1.0.0 typecheck
> tsc --skipLibCheck
src/MyComponent.tsx:385:29 - error TS2345: Argument of type '(string | number)[]' is not assignable to parameter of type 'number[]'.
Type 'string | number' is not assignable to type 'number'.
Type 'string' is not assignable to type 'number'.
385 viewableItems
~~~~~~~~~~~~~
386 .filter(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Reviewed By: rozele
Differential Revision: D53276749
Pulled By: NickGerleman
fbshipit-source-id: 3fa5c65b388a59942c106286ac502a85c583da50
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/36345
`exactOptionalPropertyTypes` is a TypeScript 4.4+ option set by users which changes behavior of optional properties, to disable accepting explicit `undefined`.
This is not enabled when using `--strict`, and is stricter than Flow, leading to most of the typings having an `| undefined` unique to TypeScript (added with https://github.com/DefinitelyTyped/DefinitelyTyped/commit/694c663a9486dbe7794d5eb894a691ee9ded318a).
We have not always followed this (I have myself previously assumed the two are equivalent). We can enforce that the convention is followed with a plugin `eslint-plugin-redundant-undefined`. This forces us to declare that every optional property accepts an explicit undefined (which Flow would allow). Alternatively, if we do not want to support this, we can enable the existing dtslint rule `no-redundant-undefined`.
Changelog:
[General][Fixed] - Enforce compatibility with `exactOptionalPropertyTypes`
Reviewed By: lunaleaps
Differential Revision: D43700862
fbshipit-source-id: 996094762b28918177521a9471d868ba87f0f263
Summary:
This change reverts D41745930 (https://github.com/facebook/react-native/commit/2e3dbe9c2fbff52448e2d5a7c1e4c96b1016cf25) 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