Expand the namingConvention to allow for overriding input types

[Soviut]

Currently we use the namingConvention config to convert our snake_case values from the database to camelCase to match our code base. However, this only works on the codegen output types, not input types. Meaning that when we perform a mutation, we have to use something like snakecase-keys to convert our mutation variables back to snake case when passing objects.

It would be really useful if the naming conventions worked for both output and input types. Making the entire round trip seamless.

[charlypoly]

Hi @Soviut!

Could you provide an example?

If I understand well, your issue is that you have to manually convert data keys to snakecase when sending it to the API?

[Soviut]

@charlypoly That's correct; we need to use snakecase-keys to turn our camelcase JS objects back into snake case before we pass them to our mutation variables. Our Postgres database uses snake case. We wrap it in Hasura to generate our graphql schema, so it uses snake case as well in the schema.

We're using the vue-apollo plugin so performing a mutation looks something like the following.

import snakecaseKeys from 'snakecase-keys'

const contact = {
  firstName: 'Joe',
  lastName: 'Blow',
  emailAddress: '[email protected]',
}

const { mutate: importClient } = useImportClientMutation({})

// need to convert to snake case here on the `client` variable to match the input type that has snakecase
await importClient({ client: snakecaseKeys(contact) })

[charlypoly]

@Soviut, thank you for the example!

Codegen cannot offer naming convention support for input types simply because it would break the type conformance with the underlying schema.
What you are looking for is Schema Transforms, which consist of transforming your existing schema with tools that will handle for you the naming convention (ex: for input types) at the schema definition level but also by transforming the data (the input type property case) on the fly.

This can be achieved with some of our tools, such as GraphQL Mesh's naming convention or GraphQL Tools transforms.

[Soviut]

@charlypoly To clarify, I'm not looking to change my schema (which is snake case), I simply would like some kind of transform step for query/mutation variables.

Basically, the inverse of what naming conventions are doing for output.

In my prior example

const contact = {
  firstName: 'Joe',
  lastName: 'Blow',
  emailAddress: '[email protected]',
}

await importClient({ client: snakecaseKeys(contact) })

I would expect client to be able to accept contact without needing to transform it manually with snakecaseKeys().

await importClient({ client: contact })

Essentially, move that transformation step into some kind of inverse of naming convention.

[charlypoly]

@Soviut, I understand your use case; however, this is not something that can be solved with GraphQL Code Generator, which only handles types generation.
My previous answer was to showcase how this would be solved the "GraphQL way", where such transforms of data should be handled on the server side.

If you want to keep those transform of input data on the client-side, I don't see a better solution than your existing one relying on some utils.

[Soviut]

@charlypoly I see. Perhaps I'm conflating the behaviour of typescript-vue-apollo plugin for codegen since it's what's generating the query functions. Maybe the plugin is where I should be trying to do the transform, or maybe I can just do the transform at the Apollo client level.

[charlypoly]

@Soviut, yes, most of the current plugins generate actual; however, they are just wrappers around clients (URQL, Apollo), not adding any business logic.
Also, we took the decision to soon move away from actual code generation in favor of types-only generation plugins that will offer the same features-set with no bundle size impact.

Still, everybody is free to develop their own plugins on top of GraphQL Code Generator 👀

[charlypoly]

Putting the answer here for visibility:

Codegen cannot offer naming convention support for input types simply because it would break the type conformance with the underlying schema. What you are looking for is Schema Transforms, which consist of transforming your existing schema with tools that will handle for you the naming convention (ex: for input types) at the schema definition level but also by transforming the data (the input type property case) on the fly.

This can be achieved with some of our tools, such as GraphQL Mesh's naming convention or GraphQL Tools transforms.