Accept de-structured elements in type predicates

[rraziel]

Search Terms

• type predicate
• reference binding pattern
• type predicate cannot reference
• destructured

Suggestion

The possibility to use destructured parameters in type predicates.

Use Cases

Destructuring is heavily used in functional/reactive programming, notably with rxjs where various contextual properties tend to be passed between each operator.

Having the ability to succinctly test for types would make the code more readable, e.g.:

type Example = {
  a: number;
  b: string | undefined;
};

const example: Example = {
  a: 42,
  b: 'hello';
};

of(example).pipe(
  guard(({ b }): b is string => b !== undefined, 'b cannot be undefined'),
  tap({ b }) => { /* b is now a string rather than a string | undefined })
);

Right now the alternative is

of(example).pipe(
  guard((x): x is Omit<typeof x, 'b'> & { b: string } => x.b !== undefined, 'b cannot be undefined'),
  tap({ b }) => { /* b is now a string rather than a string | undefined })
);

Or, without a predicate

of(example).pipe(
  map(x => {
    if (x.b === undefined) {
      throw new Error();
    }

    return x;
  }),
  tap({ b }) => { /* b is now a string rather than a string | undefined })
);

Examples

function assertSomething(
  { property }: T
): property is AssertionHere {
  return true;
}

This would roughly translate to something like:

function assertSomething(
  obj: T
): obj is Omit<T, 'property'> & { property: AssertionHere } {
  return true;
}

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

Self-contained examples that don't assume importing/knowledge of rxjs would be very helpful

[manbearwiz]

I run into this when filtering the output of Object.entries. I find it much more readable to be able to reference key and value instead of pair[0] and pair[1]. Simplified example but demonstrates a use case outside of rxjs.

If I want all pairs from the query params that are arrays, I currently have to do:

const queryParams = {text: 'foo', statuses: ['status1', 'status2'], regions: []}

Object.entries(queryParams)
 .filter((pair): pair is [string, string[]] => Array.isArray(pair[1]))

or

Object.entries(queryParams)
  .filter(([_, value]) => Array.isArray(value))
  .map(pair => pair as [string, string[]])

I would prefer to do:

Object.entries(queryParams )
  .filter(([_, value]): value is string[] => Array.isArray(value))

[rraziel]

A simple-with-no-external-elements example could be:

type X = { value: number | string; };
const xs: Array<X> = [{ value: 42 }, { value: 'hello' }];

// without the feature
const filtered = xs
  .filter(({ value }) => typeof value === 'number')
  .map(x => x as { value: number })
;

// with the feature
const filtered = xs
  .filter(({ value }): value is number => typeof value === 'number')
;

[iBlueDust]

Ran into this problem in React.

I have a React context in the form of a class.
Unfortunately, trying something like

function assertSomething(
  obj: T
): obj is Omit<T, 'property'> & { property: AssertionHere } {
  return true;
}

in my project as suggested by @rraziel doesn't work.

Turns out, since Omit<SomeClass, 'someProperty'> throws all class methods away, intellisense rejects it as incompatible with SomeClass.

In my project, intellisense reported

Type 'Omit<RoomStore, 'room'> & { room: Room; }' is missing the following properties from type 'RoomStore': client, socket, setUser, setRoom, and 10 more.

In conclusion, it'll be real nice for this feature to be implemented (or this bug to be fixed).

[artu-ole]

I agree that this is a useful feature and an unfortunate oversight on typescript's part.
I would, however, note that @rraziel's workaround example can be slightly better versed by not causing an additional loop with map and using destructuring in the filter body to preserve readability.

const filtered = xs
  .filter((x): x is { value: number } => {
    const { value } = x;
    return typeof value === 'number';
  });

Same goes for array destructuring(my use case which involved rxjs's combineLatest)

type X = [ number | string ];
const xs: Array<X> = [[ 42 ], [ 'hello' ]];

// without the feature
const filtered = xs
  .filter((x) => {
    const [ value ] = x;
    return typeof value === 'number';
  })
;

// with the feature
const filtered = xs
  .filter(([ value ]): value is number => typeof value === 'number')
;

[Susccy]

Since this has the Awaiting More Feedback label I'd like to add that this is an important feature request from me as well.

[rgfretes]

+1

[Yohandah]

In need of this feature as well !!

With the feature :

combineLatest([this.route.paramMap, this.route.queryParamMap])
      .pipe(
        map(([parameters, queryParameters]: [ParamMap, ParamMap]) => [
          parameters.get('provider'),
          queryParameters.get('code'),
        ]),
        filter(([provider, code]: (string | null)[]): code is string => provider === 'something' && code !== null),
        map(([, code]: string[]) => code),
      )
      .subscribe((code: string) => {
        //stuff
      });

[dominik-widomski-jm]

This would be pretty neat! Example of how I would have liked to use this (bit of a compacted example):

const dataFields = Array.from(formData)
    .filter(([key, value]): value is string => typeof value === "string" && ["foo"].includes(key))
    .map(([key, value]) => ({ key, value }));
    
    
fetch("some/endpoint", {
  ...
  body: JSON.stringify({ dataFields }), // dataFields type should be { key: string; value: string }[]
});

Explanation:
I'm going over a form submission, whitelisting certain fields by keys. Later when I send it to an API, I know that the value fields need to be strings where as per TS formData: FormData entries are type FormDataEntryValue = File | string;, I just don't want the File in there.

[Wytrykus]

+1

I'd like to support this suggestion, too.

[konstantinmv]

Want to support this issue as well.

Here's our case:
We've got a type which looks like the following:
{ success: boolean, result: Success[] | Error[] }

We were trying to create a predicate which shows which type of result is returned based on the boolean success value -> but since desctructuring isn't available, this does not work out so well.

Thanks in advance!

[OliverLeighC]

Another super simple example use case would be if we have

type Foo = {
  id: number;
  name?: string;
}

const foo: Foo[] = [{ id: 1, name: 'foo' }, {id: 2, name: undefined }];

this works fine:

const fooNames: string[] = foo.filter((f): f is Foo & {name: string} => f.name !== undefined)
.map(({ name }) => name);

but if the types is more complex or if you are filtering by multiple keys it would be really helpful to be able to de-structure the predicate like:

foo.filter(({ name }): name is string => name !== undefined)

[karatekid430]

Seriously, why is this not already a thing? The one time I want to use destructuring of props in a function and it does not work. Strong upvote.

[avin-kavish]

Any workaround for this when destructuring tuples?

const rolledValues = new Map<string | undefined, number>()
filter(
  rolledValues,
   ([key, value]): key is NonNullable<unknown> => !!key,
)
//  `filter` is similar to `Array.filter` but works on any iterable.

Had to write it like this, not the most convenient...

(tuple): tuple is [string | number, number] => !!tuple[0]

[Expertus777]

Since this has the Awaiting More Feedback label I'd like to add that this is an important feature request from me as well.

Me too. My use case is "Object.entries" which is already present by manbearwiz comment.

[Lonli-Lokli]

Interesting, can it be covered by #57465 ?

[MMJZ]

A whopping ten months after the last time this was asked, why are we still in "Awaiting More Feedback" on this one?

If it's possible to do it, can we just get on and do it? If it's not possible to do it, can we explicitly state that and close this off? If it's just low priority but on the wishlist, can we explicitly state that so people can avoid being confused by the silence?

[RyanCavanaugh]

@MMJZ

/~https://github.com/microsoft/TypeScript/wiki/FAQ#time-marches-on

/~https://github.com/microsoft/TypeScript/wiki/FAQ#what-kind-of-feedback-are-you-looking-for

/~https://github.com/microsoft/TypeScript/wiki/FAQ#this-is-closed-but-should-be-open-or-vice-versa

[devuxer]

@RyanCavanaugh,

Those are all good reminders, but the one thing that I see causing the most frustration is lack of transparency. What does the development team think about this issue (as far as desirability, feasibility, and priority) and what does it need the community to do to mature it enough that it can be fully evaluated?

As for this issue in particular, this is what I see:

1. OP describes problem.
2. You request a self-contained example.
3. Several self-contained examples come in.
4. No response from the development team.
5. --- time ---
6. Still no response from the development team.
7. People start to express frustration.
8. You remind us to keep it constructive, but you do not give us any insight into what the development team thinks about this issue nor explain why you are still "Awaiting More Feedback" (given the many good-faith attempts to deliver said feedback).

I understand that your time is limited, but if you are going to take the time to comment at all, the most constructive thing you could do is tell us how we can help you bring this issue to a resolution.

[aleksei-minkin-webcom]

This seems like a good feature, any news on this?