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
Error using intersection type for object rest destructuring #12520
This is using the latest release-2.1 branch. I'm unclear why types B & C would behave differently below when it comes to object rest members, so I am assuming this is a bug. (ping Nathan Shively-Sanders (@sandersn) & Mohamed Hegazy (@mhegazy) ).
interfaceA{name: string;age: number;}interfaceBextendsA{address: string;}typeC=A&{address: string};// Both v1 & v2 appear to have the same members...varv1: B;varv2: C;// ... and assignment in either direction is finev1=v2;// OKv2=v1;// OK// let {name, ...x2} = v1; // This line is valid (when uncommented)let{name, ...x3}=v2;// This line gives the error: Rest types may only be created from object types.
That's by design since (1) I don't know of a scenario that depends on it (2) I expect in 2.2 we'll have real rest and spread types that handle intersections correctly.
Currently intersections of object types are not object types themselves. They stay intersections, which makes it hard to track the difference between an intersection that contains type parameters (not usable with rest) and one that doesn't (could be usable with rest).
If this is a common scenario we can flatten all-object intersections to object types for now and revisit when we add rest types. But I would prefer to do nothing for 3.1 unless it's important.
My scenario was in trying to type a tree of React components, whereby (parts of) the model gets passed down, yet some components may also add members for some children (such as event handlers). A simplified/contrived example is below. Without intersection types working, I had to extend an interface each time I wanted to augment the type of the receiving props parameter.
Note: Subtraction types will be nice too, as often you remove a couple of props from the model then pass down the remainder - which is kind of a pain to describe accurately right now without a lot of forethought (and code).
Reacted by Aluan Haddad, Ilya Kuznetsov, Jared Russell and Ed Staub
Activity
sandersn commentedon Nov 27, 2016
billti commentedon Nov 27, 2016
My scenario was in trying to type a tree of React components, whereby (parts of) the model gets passed down, yet some components may also add members for some children (such as event handlers). A simplified/contrived example is below. Without intersection types working, I had to extend an interface each time I wanted to augment the type of the receiving props parameter.
Note: Subtraction types will be nice too, as often you remove a couple of props from the model then pass down the remainder - which is kind of a pain to describe accurately right now without a lot of forethought (and code).
mhegazy commentedon Nov 28, 2016
In cases like these we should just allow it to go through. it is rather artificial that we do not. type parameters should still be disallowed though.