Repository navigation
Consider only showing builders in object literal completions its contextual type has an index signature #4089
Description
Since users are no longer allowed to have excess properties in an object literal, it might be appropriate to only show a builder when the contextual type of an object literal has no index signature.
For instance:
type T = { x: string; y: number; };
function f(param: T) {
}
f({ /*$*/ }); // should only allow 'x' and 'y' and no builder.However, this may not be sufficient; in the presence of a type assertion, one actually does want to allow a builder, since this is one of the recommended workarounds anyway:
type T = { x: string; y: number; };
function f(param: T) {
}
f(<T>{ /*$*/ }); // should only allow 'x' and 'y' and no builder.
Activity
danquirk commentedon Jul 30, 2015
Seems like a good idea
DanielRosenwasser commentedon Jul 30, 2015
Though I recall another edge condition is that we would need to allow a builder for the empty type as well.
JsonFreeman commentedon Aug 2, 2015
I believe you would also want a builder when the contextual type is from a type assertion, because you are allowed to specify extra properties there as well.
You may want to look at isKnownProperty in the checker for inspiration.
DanielRosenwasser commentedon Aug 2, 2015
Jason Freeman (@JsonFreeman) sorry that's what I originally meant, I wrote "completion" instead of "a builder" in the original issue. Corrected.
JsonFreeman commentedon Aug 2, 2015
Yes, but I meant that maybe the builder would always be shown in a type assertion, since type assertions do not view their expressions as fresh.
DanielRosenwasser commentedon Aug 8, 2015
Right, that was what I was getting at. And actually there's another problem - consider the following:
Provided that
FooOptionsandBarOptionsare non-empty and distinct, if you supply an empty object literal tof, you are potentially going to only getBarOptions(since resolution would fail onFooOptionsand settle onBarOptions).This would be bad experience. We should either supply properties from both
FooOptionsandBarOptionsor not force completion.JsonFreeman commentedon Aug 8, 2015
I think that is a different issue. You'd need to detect whether multiple overloads are involved in obtaining the contextual type, and decide on a policy for this case. I think it may be acceptable to pick one and show a builder. Alternatively, you could try to collect them from all the overloads, but I think that would be complicated, and not that useful. I would also try to have completion and signature help agree on which overload the user is likely trying to call.
RyanCavanaugh commentedon Oct 5, 2015
We'd rather error on the side of not restricting the typing here.