Generic derived value type

Hey guys. I can not see if I’m doing anything wrong here. I am expecting to be able to get exact type from generic type … Is this just limitation of typescript or i am doing anything whrong here?

TypeScript Version: 3.1.3

Search Terms: Generic derived value type

Code

export type filterTypeName = 'price' | 'price_range';
export type priceFilterValue = {
  from: number;
  to: number;
};
export type priceRangeFilterValue = {
  fromRange: number;
  toRange: number;
};

export type filterValueType<T extends filterTypeName> =  
    T extends 'price' ? priceFilterValue
    : T extends 'price_range' ? priceRangeFilterValue : never;


type productFilterParameters<T extends filterTypeName> = {
  filter: T;
    value: filterValueType<T>;
};

function addProductFilter<T extends filterTypeName>(params: productFilterParameters<T>) { 
    switch (params.filter) { 
        case 'price':
            const priceFrom = params.value.from; //Property 'from' does not exist on type 'filterValueType<T>'    
            break;
        default:
            break;            
    }
}

// parameter value is derivered based on filter type... not working id function definition
addProductFilter({ filter: 'price', value: { from: 1, to: 2 } });

//expected behavior something like this

type productFilterParametersCorrect = {
    filter: 'price';
    value: priceFilterValue;
} | {
    filter: 'price_range';
    value: priceRangeFilterValue;
}

function addProductFilterCorrect(params: productFilterParametersCorrect) { 
    switch (params.filter) { 
        case 'price':            
            const priceFrom = params.value.from; // correct
            break;
        case 'price_range':
            const priceRangeFrom = params.value.fromRange; // correct
        default:
            break;            
    }
}

Expected behavior: Code

const value: priceFilterValue

Actual behavior: Code

const value: filterValueType<T>

Playground Link: Playground

Related Issues:

[Nathan-Fenner]

@andyrichardson The behavior is still as expected:

The reason strict null checks throws an error is because the type of arg.additionalProp is string[] | null. It should be of type null given arg has the type of MyInterface<'c'>

This isn’t the case. Given that state === 'c', you only know that 'c' is a subtype of S. In particular, (e.g.)S = 'a' | 'c' is still entirely possible:

const exampleValue: MyInterface<'a' | 'c'> = {
  state: 'c',
  additionalProp: ["foo", "bar", "baz"],
};

This value can be passed to myFun above; you’ll find that state === 'c' as expected, and also that additionalProp has type string[], not null. This works since conditional types are distributive, meaning that X | Y extends T ? A : B is really the same as (X extends T ? A : B) | (Y extends T ? A : B). This means that in the above, additionalProp really does have the type string[] | null, since 'a' follows the left path and 'c' follows the right one.

You can avoid distribution with the following trick:

interface MyInterface<S extends state> {
  state: S,
  additionalProp: [S] extends ['a'] ? string[] : never;
}

by wrapping the two types in a single-element tuple. However, this won’t actually solve the problem, because it is still impossible to distinguish (solely using flow types) that S is actually 'c' and not 'a' | 'c' or 'a' | 'b' | 'c' or 'b' | 'c' (since you can only learn what it is allowed to be, and not what it is not allowed to be, from runtime checks).

The following trick almost works, except the TS’s flow-typing is not sophisticated enough to understand that deducing S = 'c' is actually correct:

type state = 'a' | 'b' | 'c';

interface MyInterface<S extends state> {
  state: [S] extends ['a'] ? 'a' : [S] extends ['b'] ? 'b' : [S] extends ['c'] ? 'c' : null,
  additionalProp: [S] extends ['a'] ? string[] : null;
}

This makes the code actually sound (since the exampleValue above will no longer compile) since it enforces that the tag is consistently a singleton throughout the type, although you’ll need to perform a cast inside the function to convince tsc that it really behaves as intended.

[Nathan-Fenner]

The error absolutely is produced (provided that --strictNullChecks is on:

See playground for example

You obtain the error:

Object is possibly null

As expected. Your issue is due to misuse of never, not a bug in conditional types. Even then, it would be unrelated to the original issue here.