Is it possible to separate GraphQL codegen for inputs and mutations?

[ashleyxue529]

For example, I want to use the generated input type of the graphql create action for an ent, but I don't want to surface the create mutation itself.

My current setup uses nested ent input objects for one main top level create mutation; I haven't quite figured out the best way to do it. Right now I'm using this, but it's not quite what I need:

actions: [
    {
      operation: ActionOperation.Create,
      inputName: "CreateObjectInput",
      actionOnlyFields: [
        {
          name: "objectLayers",
          type: "Object",
          actionName: "CreateObjectLayerAction", <- this mutation is shown in graphiql, but i dont need it, only the input type
          list: true,
        },
        {
          name: "objectImages",
          type: "Object",
          actionName: "CreateObjectImageAction",
          list: true,
        },
      ],
    },

I guess more generally what I'm looking for is the ability to define CUD input types derived from the EntSchema classes and use those wherever I need them. Slightly related to https://github.com/lolopinto/ent/issues/1754 as I'm using this current setup as a workaround for not being able to easily nest input object types.

Also looking for the ability to reuse input types. E.g. a general CreateObjectInput can be used in multiple places, currently having some issues using the same variable names for different mutations for similar types...

[lolopinto]

is this about separating the location of the input type or the input itself?

if it's related to generating in a new location, yah, i wanna do that for all things especially after https://github.com/lolopinto/ent/pull/1776

if you're trying to codegen just the input separately, can you add some more context?

is this related to an action that's not visible to graphql so you want the action hidden but the input visible?

[lolopinto]

Also looking for the ability to reuse input types. E.g. a general CreateObjectInput can be used in multiple places, currently having some issues using the same variable names for different mutations for similar types...

hmm, how would this work?