Oh wow, that statement is so much more than I'd have expected - there's something to look forward to!
Personally, I like Flow more, and I also think its easier to integrate into an existing codebase (either as comment annotations or gradually via per-file flow comment header), but at the end of the day, not choosing TypeScript amounts to swimming against the current without much justification.
For several versions now, Typescript also supports type annotations in JS comments and an allowJS mode for mixing TS and JS in the same project, or using only JS and JS comment type annotations.
Source? That's the primary design principle behind TypeScript too. TypeScript's type system is powerful enough to practically do arbitrary type-level transformation of data structures, and even do some crazy recursive pure functional type level programming.
The only things I'm missing from TypeScript are variadic generics (which can be emulated quite well with TS 3.0) and higher kinded types - and I don't think Flow supports them either.
Most of that can't be achieved out of the box with TypeScript. TypeScript was designed as a language that would bridge the quality of life gap between es5 and more modern languages, Flow was designed exclusively as a type system for annotating standards compliant JS.
type Keys<T> = keyof T
type Values<T> = T[keyof T]
type Readonly_<T> = Readonly<T>
type Shape<T> = Partial<T>
type NonMaybeType<T> = NonNullable<T>
// Exact<T> cannot be implemented because TS doesn't have exact types as a separate concept,
// It should be noted that object literals are exact by-default if there's a type annotation
// Issue: https://github.com/Microsoft/TypeScript/issues/12936
type Diff<A, B> = Pick<A, Exclude<keyof A, keyof B>>
// Rest<T> should be equal to Diff, because TS doesn't have exact types
type ElementType<T, K extends keyof T> = T[K]
// PropertyType in unnecessary, because T[K] works for everything
// Note that this is variadic - "Args" is an array of arguments
type Call<F, Args extends any[]> = F extends (...args: Args) => infer B ? B : never
// This works for both objects and tuples.
type ObjMap<T, F> = { [K in keyof T]: Call<F, [T[K]]> }
// I couldn't figure out how to implement Class<T>, but you can access the type of a class instance with
// typeof ClassName.prototype
// $SuperType and $Subtype are not documented, so I can't try to replicate them.
// TypeScript doesn't have existential types, but you can emulate them within the type system, or avoid them using e.g "infer"
// Discussion and encoding https://github.com/Microsoft/TypeScript/issues/14466#issuecomment-338045331
[1] https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://github.com/Microsoft/TypeScript-Handbook/blob/master... [3] https://github.com/facebook/flow/blob/cf03c08109014c4503a392...
Untested and off the top my head but maybe something like:
type Values<T> = T extends { [K keyof T]: infer R } ? R : any type Props = {
age: number
name: number
}
type Values = Props[keyof Props]Why does the project generated by react-native-cli contains some flow syntax by default? this is stupid. Not everybody has a flow plugin for his IDE. And obviously flow type declarations are not valid JavaScript. I understand you want to push your stack onto your users but no need to be that invasive.
We actually did have "TypeScript support" on a nice-to-have list for this two week sprint but unfortunately didn't get to it:
https://i.imgur.com/l0CpdZy.png (I promise I'm not making this up :-)
I'm confident we'll ship it by the end of this year though.