You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tagged union common property types are not narrowed #10976
I'm wondering if there is a way to make destructuring on tagged unions a bit more ergonomic? It seems like something that would be a common pattern, and having to duplicate destructures in each case could be cumbersome.
once an object is destructed, the compiler can no longer make any assumptions about the relationships between the parts. Doing so requires data-flow analysis and alias tracking which is not trivial tasks.
This would be really nice to have. I find myself often writing type guards inside filter() callbacks
constelements=newObservable<HTMLElement|null>()elements.pipe(filter((element): element is NonNullable<typeofelement>=>!!element))
which is painful if you just want to narrow the type of one property/tuple element, because you need to repeat the type of the other members and cannot use destructuring:
constmouseOvers=newObservable<MouseEvent>()mouseOvers.pipe(withLatestFrom(elements),filter((data): data is [typeofdata[0],NonNullable<typeofdata[1]>]=>!!data[1]))
vs
mouseOvers.pipe(withLatestFrom(elements),filter(([,element]): element is NonNullable<typeofelement>=>!!element))
Activity
[-]Tagged union common properties are not narrowed[/-][+]Tagged union common property types are not narrowed[/+]farism commentedon Sep 18, 2016
Actually.. this is user error. I believe the issue lies with doing the destructure in the reducer, i.e.
Because I haven't switched on the
kindat this point, flow control analysis cannot narrow down the type ofpayload. The following works fineI'm wondering if there is a way to make destructuring on tagged unions a bit more ergonomic? It seems like something that would be a common pattern, and having to duplicate destructures in each case could be cumbersome.
mhegazy commentedon Sep 20, 2016
once an object is destructed, the compiler can no longer make any assumptions about the relationships between the parts. Doing so requires data-flow analysis and alias tracking which is not trivial tasks.
felixfbecker commentedon May 2, 2018
This would be really nice to have. I find myself often writing type guards inside
filter()callbackswhich is painful if you just want to narrow the type of one property/tuple element, because you need to repeat the type of the other members and cannot use destructuring:
vs