OneOf Input Objects in Pothos?

[bernhardw]

How can I use @oneOf Input Objects in Pothos?

Example:

input PetInput @oneOf {
  cat: CatInput
  dog: DogInput
  fish: FishInput
}

input CatInput { name: String!, numberOfLives: Int }
input DogInput { name: String!, wagsTail: Boolean }
input FishInput { name: String!, bodyLengthInMm: Int }

type Mutation {
  addPet(pet: PetInput!): Pet
}

Details: graphql/graphql-spec#825

[hayes]

This is not yet a standardized feature, and has not landed in graphql-js, see graphql/graphql-js#3513

This will need to be supported in the underlying graphql implementation before it lands in Pothos

[bernhardw]

Thanks a lot, makes perfect sense.

[i-tengfei]

@hayes Any update?

[hayes]

just pushed up some type changes that make the isOneOf option define stricter types for builder.inputObject. Thats a type-only change, the functionality for the oneOf directive was already fully supported

[vecerek]

Are there any plans to generate a tagged union type from oneOf input objects? Any way I can help?

[hayes]

Can you elaborate on how you would expect that to work, and what the issue is with the current implementation?

[vecerek]

Of course 🙂 There is not necessarily an issue with the current implementation. In my opinion, tagged unions, or sum types, represent the concept of oneOf more correctly in the type system compared to the currently generated types. Let me demonstrate this through an example.

Given the following oneOf input schema:

export const OneOfExample = builder.inputType(
  "OneOfExampleInput",
  {
    isOneOf: true,
    fields: (t) => ({
      a: t.int(),
      b: t.string(),
      c: t.boolean(),
      d: t.id(),
    })
  }
);

the generated TS type looks like this:

type OneOfExample =
  | { a: number; b?: undefined; c?: undefined; d?: undefined; }
  | { b: string; a?: undefined; c?: undefined; d?: undefined; }
  | { c: boolean; a?: undefined; b?: undefined; d?: undefined; }
  | { d: string; a?: undefined; b?: undefined; c?: undefined; }

This checks all the functional requirements but notice how the list of undefined keys grows with the number of fields in the oneOf input type. However, in practice, only one of the fields can be present at any one time, so why should we represent all the undefined options for each case? The developer experience also suffers because the IDE still presents all options:

A much better representation of oneOf is a tagged union which gets rid of the "absurd" options from the type signature. It would look something like this instead:

type OneOfExample =
  | { _tag: "a"; a: number; }
  | { _tag: "b"; b: string; }
  | { _tag: "c"; c: boolean; }
  | { _tag: "d"; d: string; }

Not only we get rid of all the noise from the type signature but the developer experience becomes also more favorable:

It is a solution that scales better with the number of fields in the input type.

[hayes]

The issue with this is that it requires a runtime change which kinda goes against Pothos design principles. Pothos pretty strictly helps you build schemas that don't contain any Pothos specific login at runtime. For the most part everything that executes to resolve a query (when not using plugins) comes either from the graphql package, or user defined resolvers.

To make this work, we'd have to wrap any resolver of fields that accept oneOf inputs, and transform the input to add the tag. This isn't trivial when the inputs are nested deeply in other input types.

If the graphql package added a tag, I would definitely update the types to reflect that, but adding runtime overhead for type convenience isn't really a good fit for core behavior.

This would be easy to do as a plugin though if you wanted to implement this yourself for your own schema