Internally at Facebook, we probably won't get to it, but it'd be awesome to see an external contribution to add Typescript type generation added.
We'd need to make sure it can live nicely alongside Flow, but the Flow type generation is pretty well isolated so that this shouldn't be an issue.
For typing the core Relay API with TS, I assume the easiest would be to add .ts files somewhere?
If there's any interest working on this, happy to chat or discuss here.
At Artsy, @xtina-starr and I have started on updating the DefinitelyTyped relay typings for Relay Modern. It鈥檚 a work in progress while we upgrade our React Native app to use Relay Modern, but that work is nearing completion, at which time we鈥檒l be able to put the finishing touches on the most important parts of the API.
We were planning to submit them back to the DefinitelyTyped repo, but if you鈥檙e willing to ship them _with_ relay that would be great.
After all of that is done, the plan was to move to the generation of TS types for our fragments.
We already tweaked printFlowTypes.js internally for this specific use.
To stick with how typing is done today (that is, if I remember correctly, without any support for interfaces or unions), the only thing that needs to be done for this specific part is to tweak the wrapNullOrArray function because '?' as in 'type foo = ?bar' is not valid syntax in TypeScript. To keep the same logic between FlowType and TypeScript, maybe simply replacing this with a union with null or undefined (if it is possible in FlowType, I can't remember) could do the trick. Other invocations of nullableTypeAnnotation in the code are ok, as is the usage of babel-generator.
@hchauvin I _think_ the right translation from FlowType to TS is type foo = bar | void.
Could just create a util type of type Maybe<T> = T | void and wrap things in that type foo = Maybe<bar>; I think this will be easier to do programmatically because the FlowTypes for relay have things like foo?: ?(bar: string) => void all over the place, which gets a bit ugly to do with unions.
@hchauvin Can you share what you鈥檝e got?
Hi sure, if there is interest I'll try to cook up something tomorrow or the day after.
To be honest is that we ended up using only the relay runtime and a very different workflow for compiling for Typescript that the one used here, so I need to work a bit on how I am going to share it.
Basically, we found out that although Babel can be used for generating Typescript, it cannot be reliably used for transforming Typescript because its support (especially around generics) is imperfect. It just doesn't parse, sometimes. So what we do, and we actually like this workflow better, is we have all our queries and mutations living in .graphql files on the side. This way, we use the compiler not for the extraction, but only for query simplification and type generation. So the question is how to separate type generation from the extraction so that the PR still makes sense as a whole. And BTW for the extraction part, I think you won't have any option but to use the Typescript compiler instead of Babel, and so incorporating Typescript support within the core repo becomes in my opinion problematic.
I'll keep you posted.
Oh I see. In that case, let me be transperant in that I am in the process of migrating our React Native app to use Babel 7, which comes with TS support. I have that part working, my next step is to make sure that Relay compiler uses that to transform its input and also to generate types (I have already played with the babel-types API and am able to easily generate TS types).
So maybe it鈥檚 more worth it to share a rough version of what you were thinking of just to see if there鈥檚 any place we could collaborate on.
For posterity, the TS typings for Relay Modern are now available as @types/relay-runtime and @types/react-relay.
Most helpful comment
For posterity, the TS typings for Relay Modern are now available as
@types/relay-runtimeand@types/react-relay.