Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Literal types support #878

Open
Open
@PinkaminaDianePie

Description

@PinkaminaDianePie

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp