unexpected return type when calling document.querySelector with a non string type argument

[goser]

TypeScript Version: v2.0.0-beta

Code

<HTMLDivElement>document.querySelector(<any>'div');

Expected behavior:

1. Get "Element" as return type like in previous versions.
   or
2. Get an error for not using a string as argument.

Actual behavior:
Compiler outputs following error:
test.ts(1,1): error TS2352: Type 'HTMLAnchorElement' cannot be converted to type 'HTMLDivElement'.
Property 'align' is missing in type 'HTMLAnchorElement'.

I think this has something to do with the changes for #8114.

[kitsonk]

Why are you coercing a string literal ('div') into an any?

[mhegazy]

querySelector is defined with a set of overloads, the relevant ones are:

querySelector(selectors: "div"): HTMLDivElement;
querySelector(selectors: "a"): HTMLAnchorElement;
....
querySelector(selectors: string): Element;
....

this tells the compiler if the argument is the literal type `"div"` the result is an HTMLDivElement, if the argument is or type `"a"` HTMLAnchorElement is returned and so on.. otherwise, if no specific tag can be determined the general element type would be provided.

so all these would result in picking the desired signature.

var d = document.querySelector('div'); // HTMLDivElement

const DivTagName: "div" = "div";
var d = document.querySelector(DivTagName); // HTMLDivElement

var d = document.querySelector(<"div">someString); // HTMLDivElement

otherwise, you will need to cast the output to the desired element type:

var d = <HTMLDivElement>document.querySelector(someString);

[Arnavion]

any is allowed to match a string literal overload, so it's matching the first overload of querySelectorAll instead of the last string one. It does seem odd, but it also makes sense given that string literals are types as well.

[RyanCavanaugh]

Returning an HTMLAnchorElement is super weird, though, and this is a breaking change. We should figure out some sort of fix.

[mhegazy]

but it is a regular type now and not a specialized signature. i do not see why we should treat them any different..

[kitsonk]

But should there be an order of precedence? When matching against any shouldn't it choose the widest? Therefore:

querySelector(selectors: string): Element;

Instead of "randomly" selecting something.

[RyanCavanaugh]

Logged #10523

[mhegazy]

doing some digging, this behavior has been there in 1.8 (see createElement), the issue is the change to the querySelector and querySelectorAll overloads happened in TS 2.0.

Instead of "randomly" selecting something.

it is not really random. overload resolution is order sensitive, it picks the first signature that matches, which happens to be the HTMLAnchorElement.

[RyanCavanaugh]

It's random to the user. We could have put those overloads in literally any order. There's no reason to expect HTMLAnchorElement any more than HTMLBaseFontElement.

[kitsonk]

Yes, which why I used "randomly" (quotes denoting perception versus reality) knowing it wasn't left up to actual chance, but to arbitrariness, which is what led to my other comment in #10523 which was that sometimes ordering of interfaces cannot be easily controlled when there is interface merging going on. There is no way of ensuring that overrides of your interfaces are ordered properly.

[goser]

@kitsonk I tried to use array elements as selectors. But I forgot to set the array type. :)

It is not a real problem for me but getting a HTMLAnchorElement feels strange.