[WIP] Connections support

[orta]

Hi there! I'm not yet at implementation stage for this, but I do want to try and spec out what the client code would look like (as that's the easiest to discuss and the biggest variable for me)

To do connections right we'll need to be able to:

• Define a ConnectionType (and allow subclassing with new root fields)
• Define a connection query (to ensure the 4 inputs that have to be there are in, but also to allow expanding with your own args)
• Define a custom edge in your connection (to allow adding metadata to the connection)
• Define the node for your connection (That's kinda the entire point of a connection)

So me + @l2succes tried speccing out two versions of how you could set it up. One with all the defaults, the simplest case. The other with every possible change. We have a mix of both in our existing codebases, so most usage falls somewhere in-between.

What do you think?

[MichalLytek]

Hi! 👋
This looks good, I'm glad that you like the Recipe example 😄

The problem is with generic types that uses reflection and decorators. You can't just provide T type to the decorator, and the syntax like:

class Edge<NodeType = {}> {
  @Field()
  node: NodeType;
  @Field()
  cursor: string;
 }

just won't work - reflection says that type of node property is Object. So I think that the @ConnectionType decorator is only to provide the node and edgeType info, right?

To achieve generic types with decorators, you have to create higher order class - a function that will take the runtime class as parameters and return new class, just like with resolvers classes:
https://19majkel94.github.io/type-graphql/docs/interfaces-and-inheritance.html#resolvers-inheritance

It's not a big deal but we have to add the isAbstract option to prevent emitting it in schema (or maybe it just works? I don't know honestly 😄). And then you just call it in a slightly different way: - extends Edge(User) instead of extends Edge<User>.

I think that if user need some additional metadata in connection or edge, he should create the classes by itself by extending the base built-in classes, just like in your advanced example:

export function <TNodeType>Edge(NodeType: TNodeType) {
  @ObjectType({ isAbstract: true })
  abstract class EdgeType {
    @Field(type => NodeType)
    node: TNodeType;
    @Field()
    cursor: string;
  }
  return EdgeType;
}

@ObjectType()
export class RecipeEdge extends Edge(Recipe) {
  @Field()
  personalNotes: string;
}

And then create his own RecipeConnection and RecipeConnectionArgs classes to handle the pagination by itself.

But for the simple example, I would make it as less verbose as it can be - just providing the information about using the pagination like @ConnectionArgs and the rest (node type) can be detected from existing decorators, without the need of manual subclassing. There should be also some built-in helpers and types for creating the connection response.

I'm afraid that it's a bit too complex feature to let newcomers make a PR as I'm not 100% sure about the API and can't provide precise tips about implementation without proper research and experimenting by my own 😕

[tonyxiao]

Related issue : #142

[orta]

Thanks for the feedback @19majkel94 - that's super reasonable, I think I agree that maybe this one might be a bit tricky for a first timer, gonna close it and keep an eye on #142 👍

[MichalLytek]

Thanks again for this PR, now I know that there's a demand for ability to extend Edge and Connection generic types 😉