Strategy for @client directive

[asci]

Hello!

What would be the strategy for @client directive? Just ignore the whole file or ignore only a client part?

Thanks

[0xcaff]

Duplicate of #275 ?

[vic08]

I'm also curious, what will be the way to handle @client directive in queries. I'm planning to manage client state with apollo but no way to generate types, when I use @client directive in the query

[kohlikohl]

Right now, having a @client directive in the query generates an error when the field that has been tagged with it is not in the schema.
It kind of makes sense that the field is not in the server-schema but maybe having the ability to feed multiple schemas (client and server schema etc) to codegen, which merges them and uses the result to validate the query would be useful.

Similar to what merge-graphql-schemas does but with the difference that all types are merged together.

[majelbstoat]

It would be great to not have to exclude the whole file, as one of the promises of apollo-link-state is that you can get client-cached and remote data all in one query (once apollographql/apollo-link-state#140 is fixed, at least). Plus, it would be good to have type-safety on even those local client operations.

Having those client fields at least set to any would be at least a useful start though.

[majelbstoat]

@kohlikohl, given that Urigo/merge-graphql-schemas#118 has been merged, do you mind sharing how you made this all work for @client directives? What did you merge together to make codegen understand the directive? Do you literally define the client-side types, Query, and Mutation in a separate file, merge them with the server ones using merge-graphql-schema, and then pass that output to codegen?

[kohlikohl]

@majelbstoat This is exactly what I am doing.

[martijnwalraven]

If anyone wants to work on incorporating a solution for this in apollo-codegen, contributions are very welcome!

[fbartho]

I'm currently pre-processing my queries to strip the @client and @rest directives, and then using code-gen to make my TypeScript types. It's working fine, but irritating that I have to strip the directives myself.

[justinmakaila]

Working on an extension for the graphql-cli-codgen tool to do just this. It uses the generate function under the hood. Most of the heavy lifting comes from the merge-graphql-schemas repo mentioned above.

[zhenwenc]

I wrote a small script to merge the remote GraphQL schema with my apollo-link-state local/client schemas, not sure if its the right way though. Hope it helps anyone.

[majelbstoat]

@zhenwenc's script worked perfectly for me. I created a clientSchema.graphql that defined the Queries and Mutations which use @client, pointed the script at that and my remote server, and it worked first time! I haven't looked at apollo-codegen's internals enough to know whether it would be a simple patch, but the approach works well. Thank you @zhenwenc!

[nihaux]

@zhenwenc thx for the snippet worked for me too 👍
Though I had to change line 79 for:
const typeDefs = mergeTypes([remoteSchema, ...clientSchemas], { all: true });
(the all: true param)

[nilshartmann]

@zhenwenc Thanks for your script, works perfect

As @nihaux mentioned, it's necessary to add { all: true } when you "extend" types from your server schema with new fields on the client, ie:

Person defined on server schema:

type Person {
  name: String
  dateOfBirth: Date!
}

Add agefield on the client schema:

type Person {
  age: Int!
}

Setting all: true on the mergeTypes call, merge-graphql-schemas actually merges both declarations into one type. Otherwise merge-graphql-schemas would fail (Type "Person" was defined more than once.)