Skip to content

String literals not contextually typed within jsx attributes #19041

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
weswigham opened this issue Oct 9, 2017 · 1 comment
Closed

String literals not contextually typed within jsx attributes #19041

weswigham opened this issue Oct 9, 2017 · 1 comment
Assignees
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue

Comments

@weswigham
Copy link
Member

Found while working on #18670 while looking over changes to contextuallyTypedStringLiteralsInJsxAttributes02. Comments in the file indicate that the goTo parameter of MainButton is supposed to be contextually typed as a literal type instead of string, but upon inspecting the type baselines you can see that it is always just string... this doesn't surface in the error baseline, since the test is simultaneously looking at excess property errors.

@mhegazy mhegazy added the Bug A bug in TypeScript label Oct 9, 2017
@mhegazy mhegazy added this to the TypeScript 2.7 milestone Oct 9, 2017
@weswigham
Copy link
Member Author

This is just a quirk of how getTypeAtLocation works, and applies to both object literals and JSX.

For example, in:

// @jsx: preserve

namespace JSX {
    export interface IntrinsicElements {
        span: {};
    }
    export interface Element {
		something?: any;
    }
}

const Foo = (props: { foo: "A" | "B" | "C" }) => <span>{props.foo}</span>;

Foo({
    foo: "B"
});

<Foo foo="B" />

In both calls to Foo, the property foo has its type baseline printed as string - the widened type of the initializer - despite that not being the contextual type (which is "A" | "B" | "C") or the inferred type for that member of the object (which is "B"). The top-level object type is built correctly, since it doesn't use getTypeOfSymbol - it uses checkPropertyAssignment on each property, which defers to checkExpressionForMutableLocation instead. It looks like using getWidenedTypeForVariableLikeDeclaration outside of checkVariableLikeDeclaration is highly suspect (since it is being expected to handle more kinds than it does). This disproportionately affects JSX baselines, since they have no top-level JsxAttributes object type baselines to inspect for correctness and more frequently have literal-typed properties (at least in our own baselines).

This is probably worth fixing, if only to make life easier for our API consumers and our type baselines actually correct, but should also make quick info accurate on JSX attributes (property assignments are already accurate, so they're likely using a special secondary code path somewhere...). Fixing this has also exposed how we don't handle literal widening on jsx attributes correctly (or at all).

@mhegazy mhegazy added the Fixed A PR has been merged for this issue label Jan 9, 2018
@microsoft microsoft locked and limited conversation to collaborators Jul 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue
Projects
None yet
Development

No branches or pull requests

2 participants