Nested Tagged Unions

TypeScript Version: 2.5.2

Code

type A = { type: "a", a: number }
type B = { type: "b", b: number }

type X = { type: A, a: string }
type Y = { type: B, b: string }

let x: X | Y

if (x.type.type === "a") {
	x.a // Type Error
}

Expected behavior:

I would expect x to have type X inside the if-statement after disambiguating the nested tagged union types.

Actual behavior:

This isn't currently how narrowing works, but we could consider expanding its rules to cover this case

Hmm. I'm surprised. So its non-recursive?

Not sure if "recursive" is the right word to apply to this situation. A discriminant property only applies to the object it's directly a member of. So in your example, inside the if block, you can access x.type.a (but not x.type.b), but there are no effects on the containing object x.

yeah, but given my type definition that seems incomplete, doesnt it?

I agree

I have run across something similar a few times, where having to peel off/unwrap properties (DOM events come to mind) and operate/assert on different parts and pieces.

It does seem to be a similar problem space to #11117, where the value of one property effects the type of another, though obviously with the above the compiler could already deduce that without any additional syntax, which #11117 would likely require.

I've been doing some digging in src/compiler/checker.ts and I guess the fix should be somewhere around here:

function isMatchingReference(source: Node, target: Node): boolean {
  switch (source.kind) {
    case SyntaxKind.Identifier:
      return target.kind === SyntaxKind.Identifier && getResolvedSymbol(<Identifier>source) === getResolvedSymbol(<Identifier>target) ||
        (target.kind === SyntaxKind.VariableDeclaration || target.kind === SyntaxKind.BindingElement) &&
        getExportSymbolOfValueSymbolIfExported(getResolvedSymbol(<Identifier>source)) === getSymbolOfNode(target);
        // || (target.kind === SyntaxKind.PropertyAccessExpression && whaever else that needs to be checked here)

Of course given the complexity of this file (createTypeChecker is a single function with ~30K lines of code), I'm not sure what the impact of this change is and what else could break from making the change.

Anyway, hope this helps, I'd really like to have this working.

Cheers!

I was about to create a suggestion along the lines of "Narrow Tagged Union Recursively".

With the following examples,

A contrived example,

type T = (
    {
        success: { value: true },
        field: number
    } |
    {
        success: { value: false }
    }
);
declare const t: T;
if (t.success.value) {
    /*
        `t`` not narrowed to
        {
            success: { value: true },
            field: number
        }
    */ 
    console.log(t.field); //Error
}

Less contrived,

type T = (
    {
        payIn: { success: true, information : string },
        payOut?: { otherInformation : string }
    } |
    {
        payIn: { success: false, error : string }
    }
);
declare const t: T;
if (t.payIn.success) {
    /*
        `t` not narrowed to
        {
            payIn: { success: true, information : string },
            payOut?: { otherInformation : string }
        }

        But `t.payIn` narrowed to
        { success: true, information : string }
    */
    console.log(t.payIn.information); //OK
    console.log(t.payOut); //Error
}

I currently am duplicating my tags to have them at every level.

Instead of:

export type DiffWithFiles =
  { diff: ModifiedFileDiff, previousFileContent: string, fileContent: string } |
  { diff: RenamedFileDiff, previousFileContent: string, fileContent: string, } |
  { diff: NewFileDiff } |
  { diff: DeletedFileDiff }

I have to do:

export type DiffWithFiles =
  { type: "modified", diff: ModifiedFileDiff, previousFileContent: string, fileContent: string } |
  { type: "renamed",  diff: RenamedFileDiff, previousFileContent: string, fileContent: string } |
  { type: "new", diff: NewFileDiff } |
  { type: "deleted", diff: DeletedFileDiff }

Where that type is identical to the nesteddiff.type field

I'm finding writing typescript with lots of these unions to be very pleasant, this would make that process simpler and more effective. Thanks for adding these ADT features to begin with!

Minor type renaming

I ended up squishing my types all down to the same level to avoid these issues. One issue with this approach is the field-name collisions, which makes it feel less composable, but if every field in all the objects have unique names then it's probably just as composable.

Like:

export type DiffWithFiles =
  ModifiedDiffWithFiles |
  RenamedDiffWithFiles |
  NewDiffWithFiles |
  DeletedDiffWithFiles


export type ModifiedDiffWithFiles = ModifiedFileDiff & {
  previousFileContent: string,
  fileContent: string
}

I haven't thought about the nesting enough to know all the implications.

I just wanted to post this so you see how the issue comes up in the real world and one possible way of people fixing it so you see what the current version of typescript is encouraging. There may be some negatives as well to allowing this nesting of unions, I'm not sure, I know in elm-lang they try to avoid nesting in general for various reasons. But if we don't have the nesting it seems that we need a way to deal with the name collision problem so we can & things together.

Unfortunately in my scenario I'm typing messages whose structure is beyond my control (i.e. they are produced by a different app).

I'd really like to have support for nested discriminant props to avoid having to have some monstrosity like:

export const isMessage = <T extends Message>(
  m: Message,
  action: T['operation']['action'],
): m is T =>
  m.operation.action === action;

That is used like:

  if (M.isMessage<M.FilePreview>(m, 'FILE_PREVIEW')) {
    return filePreview(m);
  }

When this could've been as simple as:

if (m.operation.action === 'FILE_PREVIEW') {
    return filePreview(m);
}

or even:

switch(m.operation.action) {
  case 'FILE_PREVIEW': return filePreview(m);
  ...
}

Even if this worked only with an object spread, that would help in some unambiguously valid cases:

type A = { b: 'c' | 'd'; };
type B = { b: 'c' };
const e =
    (a: A) => {
        if (a.b === 'c') {
            const f: B = { ...a }; // Error: Type '{ b: "c" | "d"; }' is not assignable to type 'B'.
        }
    };

https://www.typescriptlang.org/play/#src=type%20A%20%3D%20%7B%20b%3A%20'c'%20%7C%20'd'%3B%20%7D%3B%0D%0Atype%20B%20%3D%20%7B%20b%3A%20'c'%20%7D%3B%0D%0Aconst%20e%20%3D%0D%0A%20%20%20%20(a%3A%20A)%20%3D%3E%20%7B%0D%0A%20%20%20%20%20%20%20%20if%20(a.b%20%3D%3D%3D%20'c')%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20const%20f%3A%20B%20%3D%20%7B%20...a%20%7D%3B%20%2F%2F%20Error%3A%20Type%20'%7B%20b%3A%20%22c%22%20%7C%20%22d%22%3B%20%7D'%20is%20not%20assignable%20to%20type%20'B'.%0D%0A%20%20%20%20%20%20%20%20%7D%0D%0A%20%20%20%20%7D%3B%0D%0A

I am encountering this issue with a Redux reducer with nesting switch statements 😢

Here is an example on TypeScript Playground. Please refer to lines 43 and 46.

any updates?

+1 here. I debugged this for a bit to realize that unions can only be discriminated at the top level / direct. I'm also copying fields down the chain for this purpose

Hi, folks, if you are interested in this issue, could you do me a favour? Help check the test cases added in PR #38839.

For each test file(end with .ts), it would generate .types, .symbols and errors.txt file. I think .types file is the only file need to check.

I have found some cases are not correct(pointed out similar case by TS team member), but it is easy to miss the error.

+1. Just ran into this. I'm trying to type an object that's not in my control (comes from a third-party API response), which looks as follows (compiles correctly, but doesn't behave as expected):

{
  type: { name: 'foo' };
  settings: { a: boolean; b: string }
}
| {
  type: { name: 'bar' };
  settings: { c: string[] }
}
| {
  type: { name: 'baz' };
  settings: { d: number[] }
}

Would love to express this correctly.

Edit: For others who might stumble across this: I was able to achieve what I wanted with User Defined Type Guards. Needed a lot of boilerplate (thanks to copilot for helping out), but at least got the job done.

type SettingType<Name extends string, Settings> = {
  type: { name: Name }
  settings: Settings
};
type SettingFoo = SettingType<'foo', { a: boolean; b: string }>
type SettingBar = SettingType<'bar', { c: string[] }>
type SettingBaz = SettingType<'baz', { d: number[] }>
type Settings =
  | SettingFoo
  | SettingBar
  | SettingBaz;
const isSettingFoo = (s: Settings): s is SettingFoo => s.type.name === 'foo';
const isSettingBar = (s: Settings): s is SettingBar => s.type.name === 'bar'; 
const isSettingBaz = (s: Settings): s is SettingBaz => s.type.name === 'baz';

Rakesh Pai (@rakeshpai)

👋 currently there is a way (with some heavy type foo) to actually get this to work, I'll use Rakesh Pai (@rakeshpai) example, but others should work as well:

// The nested tagged union type
type X =
  | { type: { name: 'foo' }; settings: { a: boolean; b: string } }
  | { type: { name: 'bar' }; settings: { c: string[] } }
  | { type: { name: 'baz' }; settings: { d: number[] } };

// ========================================================================== //

// The type-level function that, given a name, returns the type(s) within the union for that name.
// The second argument is required to get "distributive conditional types" to work (more on this after
// this code snippet)
type GetTypeForName<TName, TX = X> = TX extends { type: { name: TName } }
  ? TX
  : never;

// Type predicate to run the narrowing in the outer object based on a nested discriminant
const is = <TName extends X['type']['name']>(
  x: X,
  name: TName,
): x is GetTypeForName<TName> => x.type.name === name;

// ========================================================================== //

// The function you actually wanted to write, all of the above is write-once boilerplate
const test = (x: X) => {
  // What you would like out of the box:
  // if (x.type.name === 'baz') console.log(x.settings.d);

  // What you can get, for now:
  if (is(x, 'baz')) console.log(x.settings.d);
};

You can read more about distributive conditional types here.

Also, I covered some of the building blocks for this solution ☝️ in this fan fiction story about typescript metaprogramming.

Hope this helps!

Just adding my case to this.

type Int = {
  settings: {
    fieldRule: 'Int'
  }
  selections: {
    integer: number
  }
}

type Dec = {
  settings: {
    fieldRule: 'Dec'
  }
  selections: {
    decimal: number
  }
}

function f(val: Int | Dec) {
  if (val.settings.fieldRule === 'Int') {
    console.log(val.selections.integer) // <-- error TS2339: Property 'integer' does not exist on type '{ integer: number; } | { decimal: number; }'.   Property 'integer' does not exist on type '{ decimal: number; }'.
  }
}

FWIW, it is possible to chain up the narrowing with some silly-looking code:

if (x.type.type === "a") {
    if (x.type === x.type) {
	x.a // No type error
    }
}

Adding my 2¢ here. Explicit type guards work fine to discriminate by a sub property. It would be great if implicit type guards did as well.

Playground

type A = {
    type: {
        name: "A"
    }
    a: number
}

type B = {
    type: {
        name: "B"
    }
    b: number
}

declare const aOrB: A | B

if (aOrB.type.name === "A") { // implicitly means that `aOrB` is `{ type: { name: "A" }}`
    console.log(aOrB.a) // Error
}

function hasTypeName<Name extends string>(a: { type: { name: string }}, name: Name): a is { type: { name: Name }} {
    return a.type.name === name
}

if (hasTypeName(aOrB, "A")) { // explicitly means that `aOrB` is `{ type: { name: "A" }}`
    console.log(aOrB.a) // Works
}

Can it only support (string | number)[]

As I understand it, this issue is a subset of #42384. However while propagating the inference to the parent seems very complex to implement, being able to use a nested property as a disciminator seems quite a bit simpler while covering most (?) usecases.

This is incredibly annoying and frustrating :(

My simplified issue was:

type Block = {
  type: "Element",
  tag: string,
  children: Array<Block>
} | {
  type: "Text",
  text: string
}

type BlockType = Block["type"]
type DatabaseBlock<T extends BlockType> = {
  id: string // database id
  block: Block & { type: T }
}

let foo: DatabaseBlock<BlockType> = null!;

const handle_block: {
    [K in BlockType]: (block: DatabaseBlock<K>) => void
} = {
    Text: (block) => block.block.text, // no errors
    Element: (block) => block.block.children, // no errors
}

const handler = handle_block[foo.block.type] // no error

handler(foo.block) // error

Repl

The only work around is to basically do

const handler = handle_block[foo.block.type] as (block: DatabaseBlock<BlockType>) => unknown

which is a bit more unsafe

I'd love this to be possible without a dedicated function. Even if I'd have to use dedicated syntax for this - e.g. something like this - it would go a long way:

// FAKE CODE, DO NOT USE

class BaseShape<T extends string> {
  public internal: {
    kind: T
  }
  // ...
}

class Circle extends BaseShape<"circle"> {
  public radius: number = 10;
}

class Square extends BaseShape<"square"> {
  public x: number = 10;
}

class Triamgle extends BaseShape<"triangle"> {
  public x: number = 10;
  public y: number = 10;
}

type Shape = DeepInfer<Circle | Square  | Triamgle>;
// or
type Shape = DeepInfer<Circle | Square  | Triamgle, 'internal.kind'>;

// User code:

if(a.internal.kind === "circle") {
  console.log('radius is: ', a.radius); // ts should look for nested properties to infer type of the union and assume only Circle can fit
}

Why does this matter to me? I am working on a SDK, that has typegen built in (kinda like ORM for web api). Search results of the sdk can be of any type, but each has dedicated type name described in internal object property. I can take extra code generation into typegen for recursive infering as long as user doesn't have to do anything in their code.

I don't know if performance is one of the reasons deeper nested discriminators having an effect on levels above in an object tree hasn't been realized as of yet. I'm guessing yes? If so, would tsgo's release pave the way to explore this again?

Navigation Menu

Repository navigation

Nested Tagged Unions #18758

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Nested Tagged Unions #18758

Description

Activity

RyanCavanaugh commented on Sep 26, 2017

ccorcos commented on Sep 26, 2017

RyanCavanaugh commented on Sep 26, 2017

ccorcos commented on Sep 26, 2017

RyanCavanaugh commented on Sep 26, 2017

kitsonk commented on Sep 27, 2017

pzavolinsky commented on Jul 22, 2018

AnyhowStep commented on Sep 11, 2018

amilner42 commented on Feb 6, 2019

amilner42 commented on Feb 6, 2019

pzavolinsky commented on Feb 7, 2019

jeremybparagon commented on Apr 3, 2019

3 remaining items

marcandrews commented on Jul 29, 2019

marcandrews commented on Jul 29, 2019

kevinluvian commented on Aug 27, 2019

tejasmanohar commented on Nov 1, 2019

ShuiRuTian commented on Feb 14, 2021

rakeshpai commented on Dec 7, 2021

pzavolinsky commented on Jul 1, 2022

Threnos commented on Dec 24, 2022

taralx commented on Jan 16, 2023

ericbf commented on Mar 7, 2023

crazyair commented on Aug 3, 2023

MichalMarsalek commented on Aug 28, 2024

AlbertMarashi commented on Oct 4, 2024

rgembalik commented on Dec 12, 2024

Anoesj commented on Jun 22, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions