Apollo-tooling: TypeScript codegen

[rricard]

We could generate TS types for the GraphQL queries in the project in parallel of something like graphql-document-collector to get the query docs globally.

I'll work on this in a folder parallel to the swift/ folder.

[martijnwalraven]

@rricard: Great, thanks! I just pushed a refactoring of the Swift code generator and tests that may make things easier.

[martijnwalraven]

I noticed you already started a branch, so I hope that doesn't mess up your work too much.

[rricard]

@martijnwalraven will rebase, I think I should stand in your wake!

[davidyaha]

@rricard Have you tried using the download-schema options with this package https://github.com/avantcredit/gql2ts?

[rricard]

@davidyaha interesting and no I didn't... However, in my point of view Apollo codegen is about generating types associated to the schema as well as corresponding to what's queried. So in this case, you will only get the exact type generated by the query... Which is super useful in the context of an apollo "reducer" for instance in order to ensure the input and output of the query transform are corresponding.

[davidyaha]

By the exact type generated by the query you mean the GraphQL response object?
Like this?

{
  data: {
    queryName: {
      field1: 'foo',
      field2: 'bar'
    }
  }
}

If so, it already does that. The only addition would be the loading, fetchMore and other methods returned from the apollo query, which you can add on top of the schema types.

Anyhow, was suggesting that to save you some time, but I do really want to use that types codegen goodies!

Thanks for the awesome work!

[rricard]

@davidyaha Was focusing on type annotations for now, intended to let the client handle all of the methods such as fetchMore and such (contrarily to what codegen iOS does...). When I talk about exact types, let me give you an example 😉 :

Given this schema:

schema {
  query: RootQuery
}

type RootQuery {
  strField: String
  nestField: NestedObj
}

type NestedObj {
  strField: String
  nonNullField: String!
}

And this query:

query TestQuery {
  nestField {
    strField
  }
}

I would like to generate this:

interface TestQueryResult {
  nestField: {
    strField: string | null
  }
}

From what I gathered from the tooling you are linking, you would have generated the whole type definitions for the schema. Here I only want the definitions for the query _corresponding to the schema_!

[davidyaha]

Ok so this will only solve the client side of things.
Which means that using typings on the GraphQL API server would be not possible with what your doing..

It seems to me that we could gain the server typings as well as the query typings if you add this tool to your code and basically create this kind of interface:

interface TestQueryResult {
  nestField: NestedObj
}

Where NestedObj is generated by the tool I've attached and could be used on the server as well.
Basically I would like to define my GraphQL schema, then generate typings. Create a typings package out of it, and use it in the client as well as for the server.

[rricard]

@davidyaha exactly. Right now, my main focus is client-side developer experience. Client side is usually harder and more error prone than client side in my own experience. This is still very much true with GraphQL where creating the schema is relatively easy but building a large app with large queries and such can become incrementally complex.

In the latest example you gave, to me, NestedObj may not require every field the type allows it to contain (see my example). However, NestedObjFragment can be a thing. My point is: here we're going to be query-based, because that would help with the client DX. However, and I'm glad you brought that up, gql2ts is an amazing tool for server side! Because on the server you can virtually think that everything your schema is providing is immediately available. By the way, I would love having a gql2ts-kind of project available for flow as well!

This is some great stuff discussed here, I don't think there will be one unique build tool for all of this but a bunch of complementary ones! (in a truly JS-fatigue manner, we'll figure out later how we'll make that work for beginners, let's just start by experimenting!)

[rricard]

But as you showed, tooling will be messy at first, this solution doesn't figure out how the packaging will work or anything, but, first, let's get our hands dirty and try to make something kind of work! Then, we'll refine!

[stubailo]

Yeah, I think this is a very different goal than gql2ts, which doesn't generate client-side types AFAIK.

[davidyaha]

Yep cool! Would love to see both of these tools actually. Writing typings for objects created from graphql is driving me crazy... :)

[rricard]

@davidyaha I feel you on that, got the same issue!

[rricard]

WIP in #5

[pspeter3]

Anything I can help with here?

[rricard]

@pspeter3 well, I was planning on resuming work on this issue soon (probably this WE) but I'm always open for some help. At the moment, what would be interesting is some more tests for #5.