RFC: Expose schema name in TadaDocumentNode

[ottah]

Summary

When using multiple schemas it would be useful to know what schema a TadaDocumentNode belongs to. Having this information available simplifies the need to remember and track which query-to-client combinations are required. Since we already provide a name for each schema we would just need to pass that to the TadaDocumentNode.

const MyPokemonQuery = pokemon(`
  query PokemonsList($limit: Int = 10) {
      pokemons(limit: $limit) {
        id
        name
      }
  }
`);

const {data} = useQuery(MyPokemonQuery, {
  client: MyPokemonQuery.name,
});

if(MyPokemonQuery.name === "pokemon"){
  // Do something
}

Proposed Solution

Provide a way of extracting the name of a schema from a TadaDocumentNode.

[kitten]

Hiya :wave: this is something we won't do and can't do for several reasons, let me explain ❤️

First of all — this is explained in some discussions related to enums — we don't and won't utilise codegen that generates runtime values. Hence, we have no place to put a runtime value, such as the schema.name config value. In other words, all code that gets run at runtime is user-determined, and gql.tada itself has no runtime code that is specific to a schema. This is a really important distinction, which avoids re-generation and compatibility problems, when we're talking about type-gen/code-gen, and incompatibility in your schema versions, but it also means that we won't have a place to put other values.

Second, this doesn't stop you from having user-land solutions for this. You can still emulate this by placing custom directives on your queries, or modify the graphql function to do this for you, since you'll have to create one per schema.

Third, we have to be rather strict about what the output of the graphql function is, as we're trying to align with other tools for compatibility reasons. There are many tools that remap/process GraphQL documents, and a lot may assume that they're getting a standard AST. Hence, if they copy/clone the AST, they may drop properties they don't know about, so if we added a name property, we can't guaranteee that it won't be gone if you receive an AST in other parts of your code. It would also not be typed there, since some APIs may simply type them as DocumentNode.

Lastly, multi-schema support is not meant for you to contact multiple GraphQL schemas on the client-side. In general, that's not what GraphQL is good at and doesn't play into GraphQL's strengths. You'll see in the devlog post that we carefully avoided specific phrasing to not hint at using multiple client-side schemas. That's because GraphQL quickly loses its benefits when you don't build your schemas to be client-specific, i.e. client-specified. While we acknowledge that it's sometimes beneficial (e.g. a colocated admin dashboard with an admin schema and API), that doesn't mean that this is something we'd actively support.

So, tl;dr, I can't really see the minimum crtieria here that we'd need to accept this RFC, meaning. You're not going into detail with a use-case here or something you can't do, but I think the workaround would be sufficient, if you really want to go down that route.

My recommendation hence here is to wrap the graphql function and to provide your own name property per schema. Further, if you're using multiple third-party schemas on your client-side, this isn't a supported use-case, and isn't accounted for in a lot of the GraphQL ecosystem by design.

Hope that makes sense ❤️ Happy to help further if you have more questions :v:

[ottah]

@kitten Thanks for the response. No problem if you don't want to incorporate this into the library, we have a weird setup and I noticed this would be a nice QoL change others might want too. I was thinking of going with the wrapping of the graphql function method before, so I'll go with that approach.

Love the library/tooling, just finished setting it up in my Org. Thanks for all the great work you've been doing!