.filter should narrow down output type

[ArashMotamedi]

TypeScript Version: 2.6.2

The output of filter can be a further constrained/narrowed-down type. For example, you can use filter to find items in an array that have a certain property. TS is great at inferring these constraints within the filter predicate, but should also carry the inference forward into filter results. See usage of filter and map in the example below:

Code

interface A { text?: string }
let array: A[] = [{}, {text: "hello"}, {}, {text: "world"}];
let lengths = array.filter(e => e.text).map(e => e.text.length);
                                                 ^^^^^^
// [ts] Object is possibly 'undefined'.
// (property) A.text: string | undefined

Expected behavior:
The output type of filter should be {text: string} because TS correctly understands the filter predicate: only elements with text property are returned.

Actual behavior:
The type output of filter is still {text?: string}.

[studds]

If you use a user defined type guard in combination with explicit types, you can do this. I also find it useful to use discriminated unions. I feel like it ought to be possible to cut this example down a bit further, but this is what I could put together quickly

interface A1 { }
interface A2 { text: string }
type A = A1 | A2;
const array: A[] = [{}, { text: "hello" }, {}, { text: "world" }];
const a2s: A2[] = array
    .filter((e): e is A2 => e.hasOwnProperty('text'));
const lengths = a2s
    .map(e => e.text.length);

// no compile errors

[ghost]

Duplicate of #5101 -- we won't infer that e => e.text is a type predicate without an annotation (e): e is { text: string } => e.text.

It may be easier to define a mapDefined helper like so:

function mapDefined<T, U>(array: ReadonlyArray<T>, mapFn: (x: T, i: number) => U | undefined): U[] {
    const result: U[] = [];
    for (let i = 0; i < array.length; i++) {
        const mapped = mapFn(array[i], i);
        if (mapped !== undefined) {
            result.push(mapped);
        }
    }
    return result;
}

interface A { text?: string }
let array: A[] = [{}, {text: "hello"}, {}, {text: "world"}];
let lengths = mapDefined(array, e => e.text === undefined ? undefined : e.text.length);

then there is only a single closure and type guards will work.

[JannesMeyer]

Shouldn't it be possible to leave off the explicit type on the result of .filter(), though?

interface A1 { }
interface A2 { text: string }
type A = A1 | A2;
const array: A[] = [{}, { text: "hello" }, {}, { text: "world" }];
const a2s = array
    .filter((e): e is A2 => e.hasOwnProperty('text'));
const lengths = a2s
    .map(e => e.text.length);

// The type of a2s is {}[]

It should be automatically typed like this:

const a2s: A2[];

[ghost]

@JannesMeyer In typescript@next it is.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

[seanpoulter]

Where should I add that this explicit type guard is required in the docs? We really shouldn't have to turn to GitHub to figure something like this out ...

Duplicate of #5101 -- we won't infer that e => e.text is a type predicate without an annotation (e): e is { text: string } => e.text.

[dfee]

Hello friends (who've come here before me and discovered how to do this!). Like @seanpoulter, I feel this should be documented somewhere.

For anyone coming after me, here's a practical example of how you should use something like filter:

const getNumbers = (v: Record<string, number | string>): number[] =>
  Object.keys(v)
    .map<number | string>(k => v[k])
    .filter<number>((i: number | string): i is number => typeof i === "number");

Now I'm not clear on why this is the case. Perhaps someone could enlighten us?

[edit]
I guess you could techinically drop the explicit types on map and filter:

const getNumbers = (v: Record<string, number | string>): number[] =>
  Object.keys(v)
    .map(k => v[k])
    .filter((i): i is number => typeof i === "number");

[seanpoulter]

I'd say we should add a note on the Type Inference section of the TypeScript Handbook. Let's ask the contributors of that section if they'd welcome a PR. Would you review a PR @DanielRosenwasser, @arthanzel, @RyanCavanaugh, @vomvoru, and @karptonite? Would you rather it go in Type Inference or Advanced Types?

[narkowicz]

@dfee No claim to enlightenment, but I think the core problem is summed up quite well in the original issue description and in #10734 - type narrowing doesn't flow through scopes.

The issue is unrelated to the implementation of filter which, as in your example, correctly narrows types when a type predicate is declared as the return type.

The problem is that functions never infer a type predicate as a return type. So the below isNumber function infers a return type of boolean rather than a is number and can't be used for type narrowing (consumers of isNumber correctly do not inspect the implementation, only the signature).

function isNumber(a: any) {
  return typeof a === 'number';
}

The situation is the same for inline arrow functions commonly used with filter.

What we're effectively asking for is that the type narrowing provided by an if statement (which can be quite complex) be flowed through as an inferred predicate return type when a function returns that same statement (which otherwise equates to a boolean). I can't imagine it's trivial to implement, but it would be very handy.

In such a world, the below isCardinalNumber function would also infer a return type of a is number and support type narrowing if used with filter.

function isCardinalNumber(a: any) {
  return isNumber(a) && a >= 0 && a%1 === 0;
}

[JamesMcMahon]

For those not wanting to track through multiple closed duplicate issues, this issue/discussion appears to be alive at #16069.

[SmileJayden]

After es2019, you can use flatMap.

Here is my ts-playground.

const myArr = ['hello', null, 'world', undefined];
const filteredArr = myArr.flatMap((x) => x ? x : []);

Above filteredArr is inferred as string[].

[naivefun]

in latest ts document there is the solution:
https://www.typescriptlang.org/docs/handbook/advanced-types.html

[mahmoudmoravej]

After es2019, you can use flatMap.

Although flatMap fixes the issue, but it is using a wrong tool for a specific problem: We fix typecheck error, with using an unneeded call to flat.