- Notifications
You must be signed in to change notification settings - Fork1.1k
Description
Consider adding literal types support to be able to express a union with more than a single discriminator:
typeSword {weaponType:"melee"!aptitude:"neutral"!damage:Float!}typeRifle {weaponType:"ranged"!aptitude:"technological"!damage:Float!}typeSpellbook {weaponType:"magic"!aptitude:"magical"!damage:Float!chargesLeft:Int!}unionWeapon =Sword |Rifle |Spellbook
__typename
is useless in a case where multiple discriminators are needed. Multiple discriminators allow us to write more type-safe code, usingexhaustive type check.
Currently, the only partial alternative is to use enums:
enumWeaponType { melee ranged magic}enumItemAptitude { neutral technological magical}typeSword {weaponType:WeaponType!aptitude:ItemAptitude!damage:Float!}typeRifle {weaponType:WeaponType!aptitude:ItemAptitude!damage:Float!}typeSpellbook {weaponType:WeaponType!aptitude:ItemAptitude!damage:Float!chargesLeft:Int!}unionWeapon =Sword |Rifle |Spellbook
The problem is that it doesn't allow to use of different properties as union discriminators. Consider such a react component:
constWeaponFrame=({weapon, children}:Props):JSX.Element=>{switch(weapon.type){case'melee':return<MeleeWeaponFrame>{children}</MeleeWeaponFrame>;case'ranged':return<RangedWeaponFrameammo={player.ammo}>{children}</RangedWeaponFrame>;case'magic':return<MagicWeaponFramecharges={weapon.chargesLeft}>{children}</MagicWeaponFrame>;default:((_:never)=>_)(weapon.type);thrownewError('unreachable case');}}
here I know that if type of weapon is magical, I need to displaychargesLeft
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.