Literal types support

[PinkaminaDianePie]

Consider adding literal types support to be able to express a union with more than a single discriminator:

type Sword {
  weaponType: "melee"!
  aptitude: "neutral"!
  damage: Float!
}

type Rifle {
  weaponType: "ranged"!
  aptitude: "technological"!
  damage: Float!
}

type Spellbook {
  weaponType: "magic"!
  aptitude: "magical"!
  damage: Float!
  chargesLeft: Int!
}

union Weapon = Sword | Rifle | Spellbook

__typename is useless in a case where multiple discriminators are needed. Multiple discriminators allow us to write more type-safe code, using exhaustive type check.
Currently, the only partial alternative is to use enums:

enum WeaponType {
  melee
  ranged
  magic
}

enum ItemAptitude {
  neutral
  technological
  magical
}

type Sword {
  weaponType: WeaponType!
  aptitude: ItemAptitude!
  damage: Float!
}

type Rifle {
  weaponType: WeaponType!
  aptitude: ItemAptitude!
  damage: Float!
}

type Spellbook {
  weaponType: WeaponType!
  aptitude: ItemAptitude!
  damage: Float!
  chargesLeft: Int!
}

union Weapon = Sword | Rifle | Spellbook

The problem is that it doesn't allow to use of different properties as union discriminators. Consider such a react component:

const WeaponFrame = ({weapon, children}: Props): JSX.Element => {
  switch (weapon.type) {
    case 'melee':
      return <MeleeWeaponFrame>{children}</MeleeWeaponFrame>;
    case 'ranged':
      return <RangedWeaponFrame ammo={player.ammo}>{children}</RangedWeaponFrame>;
    case 'magic':
      return <MagicWeaponFrame charges={weapon.chargesLeft}>{children}</MagicWeaponFrame>;
    default:
      ((_: never) => _)(weapon.type);
      throw new Error('unreachable case');
  }
}

here I know that if type of weapon is magical, I need to display chargesLeft property. however, it's impossible to represent it in graphql, so it's also impossible to generate a typescript type from a schema.

The only solutions left is to give up on type safety and hope that every developer won't forget to check every case, or just give up on generating types from the graphql schema and instead write all of them manually, casting graphql query results to manual typings on API level. Any of these solutions have multiple points of failure, so there is no easy and safe way to represent such kind of data at this moment.

[n1ru4l]

You could model those literal types using interfaces:

interface MagicalItem {
  magic: Boolean!
}
interface RangedItem {
  ranged: Boolean!
}
interface MeeleItem {
 meele: Boolean!
}
interface NeutralItemAptitude {
  neutral: Boolean!
}
interface TechnologicalItemAptitude {
  technological: Boolean!
}
interface MagicalItemAptitute {
  magical: Boolean!
}

type Sword implements MeeleItem, NeutralItemAptitude {
  meele: Boolean!
  neutral: Boolean!
  damage: Float!
}
type Rifle implements RangedItem, TechnologicalItemAptitude {
  ranged: Boolean!
  technological: Boolean!
  damage: Float!
}
type Spellbook implements MagicItem, MagicalItemAptitude {
  magic: Boolean!
  magical: Boolean!
}
union Weapon = Sword | Rifle | Spellbook

That would allow discriminating a generated union types with a property in object check in TypeScript.

if ('ranged' in item) {
  // thing must implement the RangedItem interface ☑️
}
if ('magic' in item || 'technological' in item) {
  // thing must implement either MagicItem or TechnologicalAptitude interface ☑️
}

[PinkaminaDianePie]

@n1ru4l that's not a solution, because it doesn't allow us to use exhaustive type check === solution is not type-safe, and even less type-safe than creating the types manually and casting them manually on API level. Consider a case, when devs will need to add a new weaponType. In that case, all of the checks I did with using switch will trigger an error for them, so they will see all of the places they need to change. Same with removal of a particular weaponType - devs will see all of the places to fix, without even running a single test. An exhaustive type check forces you to cover all of the cases, so you won't accidentally forget it. Having multiple boolean flags gives nothing. It's more safe to create all of the types manually and cast graphql results to these types on API level, so only API part will be our point of failure. Using boolean flags will make the entire codebase unsafe, so it will be much harder to spot the bug then with type casts in a single place.

[n1ru4l]

Example code and "switch" alternative using if statements:

https://www.typescriptlang.org/play?#code/C4TwDgpgBAyg7gewE4BMoF4oG8BQUoC2EEANhAFxQBGCCZAhgHZ5SMQCuwS9JlNdEJixT0C9AOYVW7AlQhIcAXxyhIUAEoBLAGZl8mXPm6NJKPrQbN8wCAGMAFozoJxm2z3MCh+EWMmVGGTkFZVVoGEgSEn4AawxsFj83T0tEiTcPagtBKyhfCSlA2XkWB3okSQBnABkIbWAAoJLlFXBoAHVBMARGePhkNAAfDR09YYjSaNoYnBxbHsrgKCQIRhR5AFliMk76bt7MAAoiUghd-cp+1ABKDAA+BKMIYHYkXsCopVn5xkXl1fWSHUTFM5x68UOxlBXR6lC0uggt3QD0M-xeb2knxaPz+KzWm3StjBBygx0JxMukSmCBiSJRLBW6Pe7Cx3wWS0kwAAIqIChC4DDGJRiddGlF7o8oDpSQAiE5kGVS3oCvY9W6op5M-74pBbU7Ew4q-bXFjKfDSw4yqEQFCKzTKwXqlia169PGA4EmG0Go1q01QBnPV3awEbcmCw2OpRAA

Your described case where a new weapon type is introduced:

https://www.typescriptlang.org/play?ssl=44&ssc=2&pln=1&pc=1#code/C4TwDgpgBAyg7gewE4BMoF4oG8BQUoC2EEANhAFxQBGCCZAhgHZ5SMQCuwS9JlNdEJixT0C9AOYVW7AlQhIcAXxyhIUAEoBLAGZl8mXPm6NJKPrQbN8wCAGMAFozoJxm2z3MCh+EWMmVGGTkFZVVoGEgSEn4AawxsFj83T0tEiTcPagtBKyhfCSlA2XkWB3okSQBnABkIbWAAoJLQ8GgAUQAPMBIESs0AN2gDFggunr7BlJzhUQLG4pCcFVaoAHVBMARGePhkNAAfDR09Q4jSaNo4w87u3oGIJdstyuAoJAhGFHkAWWIydfom22mAAFERSBAAUDKLtUABKDAAPgSRggwHYSG2gSiSkez1e70+8nUTFMUK28RBxjJGy2lC0uggCPQyMMbzRGKx7BxyhwT0YL3ZRKQ33StnJwKgYLFEphkQuCBizNZLHe6Mx0h5eIFr0kwAAIrNJJS4LTGJQJXDGlEkSioDopQAicFkR327amwFbBFs1Hq7aEr4iv6Qs0gz1AuEsZT4B0gx3UiAoN2aD1mn0sP2coVBkkmJMS8Pp6NQVUcjWBn4ysMR71KIA

As you can see the introduction of a new type results in a TypeScript error.

Please also differentiate between "not the optimal solution that you desire" and "not a solution".

As mentioned on Discord before, there is definitely some room for improvement here and literal types might be a possible solution for making this more convenient.

[PinkaminaDianePie]

now open your second link and change the union to type Weapon = Sword | Spellbook. type check will pass, while it clearly should trigger an error. exhaustive type check should work in both directions, not only "when things are right".

if the solution requires to change the data model, introduce lots of unnecessary fields, throws away standard TS way to iterate over union but fails to detect the error anyway - that's not "not the optimal solution", that's just "not a solution"

[n1ru4l]

@PinkaminaDianePie This can be used as a workaround:

https://www.typescriptlang.org/play?#code/C4TwDgpgBAyg7gewE4BMoF4oG8BQUoC2EEANhAFxQBGCCZAhgHZ5SMQCuwS9JlNdEJixT0C9AOYVW7AlQhIcAXxyhIUAEoBLAGZl8mXPm6NJKPrQbN8wCAGMAFozoJxm2z3MCh+EWMmVGGTkFZVVoGEgSEn4AawxsFj83T0tEiTcPagtBKyhfCSlA2XkWB3okSQBnABkIbWAAoJLQ8GgAUQAPMBIESs0AN2gDFggunr7BlJzhUQLG4pCcFVaoAHVBMARGePhkNAAfDR09Q4jSaNo4w87u3oGIJdstyuAoJAhGFHkAWWIydfom22mAAFERSBAAUDKLtUABKDAAPgSRggwHYSG2gSiSkez1e70+8nUTFMUK28RBxjJGy2lC0uggCPQyMMbzRGKx7BxyhwT0YL3ZRKQ33StnJwKgYLFEphkQuCBizNZLHe6Mx0h5eIFr0kwAAIrNJJS4LTGJQJXDGlEkSioDopQAicFkR327amwEUgBk3qgnqBADoXUy7aj1dtCV8RX9IWaQQGtnCWMp8A6QY7qRAUG7NB6zVBff6zYGsygEWzw5yhdGSSZsxKE2bk-hFFBVRyNVGfjL44nGMnFEA

---->

https://www.typescriptlang.org/play?#code/C4TwDgpgBAyg7gewE4BMoF4oG8BQUoC2EEANhAFxQBGCCZAhgHZ5SMQCuwS9JlNdEJixT0C9AOYVW7AlQhIcAXxyhIUAEoBLAGZl8mXPm6NJKPrQbN8wCAGMAFozoJxm2z3MCh+EWMmVGGTkFZVVoGEgSEn4AawxsFj83T0tEiTcPagtBKyhfCSlA2XkWB3okSQBnABkIbWAAoJLQ8GgAUQAPMBIESs0AN2gDFggunr7BlJzhUQLG4pCcFVaoAHVBMARGePhkNAAfWEjo2jjDzu7egYgl2y3K4CgkCEYUeQBZYjJ1+k3tzAAFERSBAfn9KLtUABKDAAPgSRggwHYSG2gSiSlu90ez1e8nUTFMYK28QBxiJGy2lC0uggMPQ8MMTyRKLR7Axyhwd0YD2ZeKQ73StmJ-ygQKFIohx1i9MZLGeyNR0g5WJ5j0kwAAIrNJKS4JTGJQRVDGlE4QioDoxQAiYFka2W7b634kgBkrqgzr+ADo7XSLYjFdtcW8BV9QQaAV6tlCWMp8FaAdbyRAUA7NE6DVB3Z6Dd6UygYUzA6y+aGCSZUyKowbY-hFFB5SylSGPhLI9HGLHFEA

[n1ru4l]

Regarding the proposal, could the introduction of exact enum field types be a possible solution?

enum WeaponType {
  melee
  ranged
  magic
}

enum ItemAptitude {
  neutral
  technological
  magical
}

type Sword {
  weaponType: WeaponType.melee!
  aptitude: ItemAptitude.neutral!
  damage: Float!
}

type Rifle {
  weaponType: WeaponType.ranged!
  aptitude: ItemAptitude.technological!
  damage: Float!
}

type Spellbook {
  weaponType: WeaponType.magic!
  aptitude: ItemAptitude.magical!
  damage: Float!
  chargesLeft: Int!
}

[PinkaminaDianePie]

In my particular case, exact enums would solve all the issues I have. The only problem is that it works only with strings, but I saw some cases where people used number/boolean literals as discriminators. Not sure how common is this case, but that's probably a separate topic - allowing enum to have boolean/numeric values is a nice thing to have, but not mandatory to solve the issue we talk about. I'd be happy to see either solution

[mdecurtins]

+1 Exact enums would be a useful construct, particularly in the absence of generics.

[n1ru4l]

I created this branch where I added parser and printer support for exact enums, it was a fun experience diving into the parser and lexer: https://github.com/graphql/graphql-js/compare/main...n1ru4l:feat-exact-named-type-node?expand=1

This is still far from an RFC, but I am just experimenting a bit with it for now!

[yaacovCR]

Would a Union of Interfaces help? You can use the schema to automatically generate type predicates that check whether a received concrete type satisfies an interface based simply on the type name. This is similar to suggestion above, but avoids booleans

[n1ru4l]

@yaacovCR One drawback of that solution is that the functions can become quite large if there are a lot of types within the schema.

This solution would also work with the boolean solution (but less verbose as type names tend to be longer).

In contrast, the exact enums approach would not require generating any function code.

[yaacovCR]

Although I am in favor of literals in general mostly because of why not

[yaacovCR]

@yaacovCR One drawback of that solution is that the functions can become quite large if there are a lot of types within the schema.

This solution would also work with the boolean solution (but less verbose as type names tend to be longer).

In contrast, the exact enums approach would not require generating any function code.

True. To clarify, you would need a generated predicate per interface, not per concrete implementation.

The good news is that you would have symmetry between your runtime types and the graphql types instead of so that could be an organizational plus.

Those predicates might be handy anyway. Imagine if you already had such an interface setup, for example. We are talking about introducing it to solve this problem, but I bet a lot of schemas already use interfaces, and such predicates would also help them.

Maybe TypedDocumentNode would already solve this problem also...

[PinkaminaDianePie]

I don't understand how the union of interfaces would help. I want to specify that some particular interface has a field with literal type as a value. It doesn't matter if we have types or interfaces, autogenerated code, and so on, I just want to restrict the value of one particular field to a literal on a schema level to generate proper TS types and I can't do it.

[yaacovCR]

It wouldn't help you have a literal type for a field, but it would help you create a system for discriminating between related types on the client exhaustively using TS typings -- in this case identical to native graphql types. I thought that was the end goal.