You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How can we offer distinctive sets of typings for iOS and Android (eg @types/react-native-ios, @types/react-native-android) and let the user configure them for their project?
Can DT handle this?
And can other DT packages that depend on RN use this too?
Many (all?) components are no longer class based, but rather function or even ‘abstract’ based. Because classes can be used as types in TS, there may be user code that refers to it that way but now needs to change to typeof View. This does not seem like an issue we need to resolve, as it’s simply not in line with reality. TS2749
There are many more component props interfaces still missing.
Should we add ElementProps to the React DT typings and is it correct that ElementProps does not include ref (as we use ComponentPropsWithoutRef of the React DT typings)?
Allow interface merging of RN NativeModules. These contain the user's own and 3rd party native modules and so should allow for the user to provide typings. f41628c
TypeScript does not have a build in way to deal with different files for different platforms.
How can we offer distinctive sets of typings for iOS and Android (eg @types/react-native-ios, @types/react-native-android) and let the user configure them for their project?
Perhaps we can find a way to alias @types/react-native-ios to @types/react-native in tsconfig.json, that way people can have different configs per platform and importing from the react-native namespace should still work.
TS doesn't need to resolve specific extensions, as currently we’re generating distinctive sets per platform and dropping the platform file extension.
And can other DT packages that depend on RN use this too?
Additionally we could update the actual @types/react-native package to import and re-export the top-level exports of both @types/react-native-ios and @types/react-native-android so they can possibly depend on them in a platform independent manner? Unsure how feasible this is.
This ticket describes the differences with the existing manually maintained DT typings and the migration path to these converted ones.
TypeScript does not have a build in way to deal with different files for different platforms. Proposal: Allow typescript to type check modules using react-native's module resolution TypeScript#21926
@types/react-native-ios
,@types/react-native-android
) and let the user configure them for their project?Many (all?) components are no longer class based, but rather function or even ‘abstract’ based. Because classes can be used as types in TS, there may be user code that refers to it that way but now needs to change to
typeof View
. This does not seem like an issue we need to resolve, as it’s simply not in line with reality.TS2749
Component props interfaces are exported, whereas upstream Flow code requires the user to do
React.ElementProps<typeof View>
. We currently export these separate props types as a migration convenience, but they are annotated as being deprecated.ElementProps
to the React DT typings and is it correct thatElementProps
does not includeref
(as we useComponentPropsWithoutRef
of the React DT typings)?Allow interface merging of RN
NativeModules
. These contain the user's own and 3rd party native modules and so should allow for the user to provide typings. f41628cStyle type param passed to
StyleSheet.create<T>(…)
needs to by atype
alias, not an interface; because Index signature is missing in type (only on interfaces, not on type alias) TypeScript#15300 (comment). But also there's no longer a need to define the type upfront anymore (which perhaps was already no longer needed).The text was updated successfully, but these errors were encountered: