Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36346
1. Remove Paper native assertions for converting DimensionValue string to Yoga unit, and fix a case where Fabric could throw on invalid value.
2. Move DimensionValue types in TypeScript to use template literal types, to show malformed strings in-editor, during typechecking. Update min TS version to allow this (in conformance with the min TS version used by DefinitelyTyped).
Changelog:
[General][Added] - Improve handling of invalid DimensionValue usage
Reviewed By: javache
Differential Revision: D43153075
fbshipit-source-id: db4e813df6e81cbd3158edad7c07c7a90c009803
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:
currently, using TS, this is a valid import:
`import { EventEmitter } from 'react-native';`
However, looking at the [index file](https://github.com/facebook/react-native/blob/main/index.js) we can see that there is no such export.
I first thought I'd add the EventEmitter export in order to get the `index.js` in line with the types, but it appears that the Event Emitter will become a separate package at some point https://github.com/facebook/react-native/pull/34401 so removing it from the types seems to be better for future.
## Changelog
fix: remove unavailable EventEmitter TS export
Pick one each for the category and type tags:
[INTERNAL] [CHANGED] - remove unavailable EventEmitter TS export
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/36109
Test Plan: tested locally: using `import { EventEmitter } from 'react-native';` correctly gives `TS2305: Module '"react-native"' has no exported member 'EventEmitter'.`
Reviewed By: javache, cortinico
Differential Revision: D43155568
Pulled By: NickGerleman
fbshipit-source-id: b9e8c3f4be9812637c8588d14a9ce4edf188ed36
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
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:
This fixes some style errors found by dtslint, along with some test cases for StyleSheet.compose() where the recent change made it slightly too permissive when explicit return types are given. I also added runs of the TS tests to a script which runs in sandcastle so we can catch this at diff-submission time in the future.
Changelog:
[General][Fixed] - Fix Errors with TypeScript Tests
Reviewed By: lunaleaps
Differential Revision: D42085257
fbshipit-source-id: 7e6ca49d3c3aef822c61c97ecc07b55b0a949d51
Summary:
This is exported from the RN entrypoint and documented on the RN website, so we should give types for it.
Changelog:
[General][Fixed] - Add type for RootTagContext
Reviewed By: christophpurrer
Differential Revision: D42040806
fbshipit-source-id: cb8cdf557098ddbe33c143b7ab5d80bda7f80a6e
Summary:
Encountered this, causing typechecking to fail on an example in the current RN documentation.
`onFail` is an optional parameter (see https://github.com/facebook/react/blob/8e2bde6f2751aa6335f3cef488c05c3ea08e074a/packages/react-native-renderer/src/ReactNativeTypes.js#L106), which is not optional in current TS types. Update the TS typings to match.
Note that "?" here is positioned to be a Flow optional parameter, instead of a maybe type. Which means it accepts undefined, but not null, matching the TS usage of "?" which always means possibly undefined (but never null, like a flow maybe type allows).
Changelog:
[General][Fixed] - Fix TS Type for measureLayout optional parameter
Reviewed By: lunaleaps
Differential Revision: D41775900
fbshipit-source-id: 8f53428b8077ec9139c7c1bbc60ed20f5fa9f7ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35169
This reorganizes typing structure a bit.
`Utilities.d.ts` was originally added for utilitiy types but I ended up leaving it a grab bag of types that didn't belong to any individual bit of code. Out of what is in it right now, `Insets` was actually public, and seems to have been imported.
We also run into files around the renderer which are [currently overwritten](https://github.com/facebook/react-native/commits/e286da25fc83324363486eb668806aca179f74b3/Libraries/Renderer/implementations/ReactNativeRenderer.d.ts) by the React sync script.
Finally, all of the top-level imports of `Utilities` were auto-generated by VS Code, but fail in real apps. I think this is because our tsconfig sets a `baseUrl` to allow resolution from the types folder, so the tooling in the RN repo will use that, but it breaks in real apps that don't have that mapping.
This splits all these up into a couple separate directories that are hopefully easier to reason about, and removes `Omit` which has been a builtin type for quite some time (we were actually already using built-in `Omit`).
Changelog:
[General][Fixed] - Fixup TS Organization
Reviewed By: cipolleschi
Differential Revision: D40932319
fbshipit-source-id: 0b6e3e3eda603885b4dc01dcb9f5233aa546d128
Summary:
Changelog:
[General][Added] - Introduce `useAnimatedValue` hook to make it easier working with `Animated.Value`s in function components.
Reviewed By: javache
Differential Revision: D40434219
fbshipit-source-id: 3caf6ad98d11a534b8cc6816820bc1d125150380
Summary:
I fixed the TypeScript definitions for Systrace in https://github.com/facebook/react-native/commit/a0f56adb07dd21ee69ad1942e9d485586f1c3ec0, but I forgot to update the TypeScript tests that were outdated. This diff fixes those tests and CI in OSS.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40141920
fbshipit-source-id: f73501450af0be6b0b6f836b9a774abb1fa4f620
Summary:
This refactors the systrace module to:
1) Migrate it to ESM
2) Fix the typing of certain parameters (e.g.: `eventName` and `cookie` shouldn't be optional)
2) Fix TypeScript definitions
3) Add inline documentation for methods
4) Add args (metadata) to all methods where it's supported in fbsystrace (`endEvent` and `endAsyncEvent`).
5) Make `setEnabled` a no-op. The only place where this method is called is from native, when starting a profile session. The problem is that implementation for Systrace in OSS (https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/systrace/Systrace.java#L40-L42) doesn't support listeners, so this wouldn't work correctly there. It also doesn't get called with Venice, so instead of fixing it for Venice with the same Meta-internal behavior, I decided to fix it for everyone with the synchronous method.
I'm not considering this a change in the public API of systrace because this module has been broken in OSS for ages and I'm assuming no one's using it at this point.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095842
fbshipit-source-id: fee41b2b7ae23aefe059e390c55d139db75247c5
Summary:
Sync the changes in `types/react-native` https://github.com/DefinitelyTyped/DefinitelyTyped/pull/62394 to here as required by lunaleaps
## Changelog
[Internal] [Added] - Sync new changes in `types/react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/34794
Test Plan: Tested in `types/__typetests__/index.tsx`
Reviewed By: cortinico
Differential Revision: D39846101
Pulled By: cortinico
fbshipit-source-id: cebe62aa97f764d9a10c8371936870c515fb9be3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34801
D39796598 (https://github.com/facebook/react-native/commit/8cdc9e7f04e2dd3026d15dcd5765952bfb2c5c08) broke this CircleCI job, causing failures for `dtslint` and `prettier`. This fixes both issues, by upating formatting, and removing types from `legacy-properties.d.ts` that we no longer export.
These were not flagged by sandcastle. It looks like this is because:
1. We run eslint, but not dtslint internally
2. Arcanist will ignore anything under a "vendor" directory, while we do not exlude anything from the prettier check in OSS.
I also updated the eslint config to lint any TypeScript that appears outside the types directory, since typings are now spread out.
Changelog:
[Internal][Fixed] - Fix `analyze_code` CircleCI Job
Reviewed By: cipolleschi
Differential Revision: D39848604
fbshipit-source-id: 844dfe26e4b618059542b29df163402079c39322
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:
The prop is removed as part of D39589089 (https://github.com/facebook/react-native/commit/bc5cb7cd7933da707c02ff0dd993c607ba7d40b3) (no longer does anything). Remove from the TS declarations.
Changelog:
[General][Removed] - Remove listKey from TS typings
Reviewed By: lunaleaps
Differential Revision: D39650827
fbshipit-source-id: dd9b5eccba1b9f6964a6d60ea5bae9913e8396e3
Summary: Changelog: [Internal] - Update the base accessibility props to include the added aria props. See https://github.com/facebook/react-native/compare/0.70-stable...main for changes.
Reviewed By: cipolleschi
Differential Revision: D39633224
fbshipit-source-id: 6c08ab8540b8b6e2b57f066a35754376c5ae3d68
Summary: Changelog: [Internal] - Update changes to Keyboard, Alert from differences in those files from https://github.com/facebook/react-native/compare/0.70-stable...main
Reviewed By: NickGerleman
Differential Revision: D39629997
fbshipit-source-id: 85bb91d00a165e708dbf4e32d7f37ce8a6c02a72
Summary:
## Changelog
[General] [Added] - Add `types` folder to house TypeScript types.
Release TypesScript types with react-native and eventually deprecate [types/react-native](https://www.npmjs.com/package/types/react-native).
The current plan is to release types/react-native for 0.70 and 0.71 while also maintaining types here. This will result in some double maintenance until 0.72 but will give community time to move off of types/react-native.
After this lands, there have been changes on `main` of types that we need to update. Then, when we release 0.71 from DefinitelyTyped, we can simply copy over the `types` folder from this repo.
Pull Request resolved: https://github.com/facebook/react-native/pull/34614
Test Plan:
`yarn run test-typescript` for linting types
* Created a new project using the TS template and my local clone of `react-native` on this branch.
`npx react-native init MyTSApp --version <path-to-my-local-rn-repo> --template react-native-template-typescript`
* Updated the `package.json` to remove `types/react-native`
* Deleted my node_modules and re-ran yarn
* Opened MyTSApp in VSCode and verified the type suggestions appeared and cmd+click to defnitions took me to the node_module dependency `react-native/types`
## Danger is failing on this PR and it's expected
as it runs off the changes on `main`. [This is expected](https://docs.github.com/en/github-ae@latest/actions/using-workflows/events-that-trigger-workflows?fbclid=IwAR2_AE0Jwndt8Gu-iTQnxGxLJq7nakbi7sz8jwZ6U62JWLSdcZuvjcQ6WvE#pull_request_target). However testing it locally passes. Once merged, and these changes are on `main`, danger will pass again.
```
$ react-native/packages/react-native-bots
❯ yarn danger pr https://github.com/facebook/react-native/pull/34614
yarn run v1.22.19
$ ..react-native/node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34614
Starting Danger PR on facebook/react-native#34614
Danger: ✓ found only warnings, not failing the build
## Warnings
🔒 package.json - <i>Changes were made to package.json. This will require a manual import by a Facebook employee.</i>
✨ Done in 13.24s.
```
Reviewed By: mdvacca
Differential Revision: D39479137
Pulled By: lunaleaps
fbshipit-source-id: 1d506f812d566b783b6e79104cd6339b077a42a7