Open rraziel opened 3 years ago
Self-contained examples that don't assume importing/knowledge of rxjs would be very helpful
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))
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')
;
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).
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')
;
Since this has the Awaiting More Feedback label I'd like to add that this is an important feature request from me as well.
+1
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
});
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.
+1
I'd like to support this suggestion, too.
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!
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)
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.
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]
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.
Interesting, can it be covered by https://github.com/microsoft/TypeScript/pull/57465 ?
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,
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:
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.
Search Terms
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.:
Right now the alternative is
Or, without a predicate
Examples
This would roughly translate to something like:
Checklist
My suggestion meets these guidelines: