Primitive type guards require typeof to be on the left hand side of the comparison

[dargoner]

Typecript method, the parameter does not support the function and the character of the joint type, prompt TS2345 error

[yortus]

The error goes away for me after re-arranging the type guards in on as follows:

    ...
    if (typeof fn == "string") {

    }
    if (typeof fn != "function" || !type) {
        return false;
    }
    ...

[mindplay-dk]

I'm running into something similar.

I'm getting the error about parentElement here even though the statement is wrapped in isHTMLElement which returns an assertion that should make parentElement known as HTMLElement inside that block.

[yortus]

Note the following compiler behaviour (with typescript@next at least):

function foo(x: string|number) {
    if (typeof x === "string") {
        x // x is narrowed to string here
    }

    if ("string" === typeof x) {
        x // x is NOT narrowed here, still string|number
    }
}

Seems weird that the two equivalent forms are treated differently. But that's what it does at present.

[yortus]

@mindplay-dk I think yours is a different problem - on the error line you linked to, the parentElement reference is inside the body of a nested function expression. Narrowing doesn't cross function boundaries except in very specific cases (see #8849).

[sandersn]

The spec provides only a few fixed forms for narrowing primitives. typeof x === 'string' narrows, but 'string' === typeof x does not.

As a workaround, you can write a type predicate:

function isString(x: any): x is string {
  return "string" == typeof x;
}
// later...
if (isString(fn) || !type) {
  return false;
}

[sandersn]

We discussed this offline and decided to change the spec in this case.

[mindplay-dk]

Narrowing doesn't cross function boundaries

@yortus why not? this works with 1.8.10, it only started failing with the nightly.

[yortus]

@mindplay-dk control flow based type analysis (landed in #8010) has tightened up type guard type inference. You are right that it appears narrowing does cross function boundaries in v1.8, but the new behaviour is more accurate. The compiler does not know whether the function expression will be called immediately, or perhaps later, by which time parentElement might have been reassigned and no longer satisfy the type guard. That is, the parentElement reference is lexically nested inside the type guard, but may not be temporally nested. So control flow analysis makes the conservative assumption not to narrow inside the function expression body.

The workaround is straightforward but a bit ugly - just introduce a new variable of the narrowed type inside the guarded block:

...
if (isHTMLElement(parentElement)) {
    const parentHTMLElement = parentElement;
    var nodes = toArray(parentElement.querySelectorAll(inlineElementSelector) as NodeListOf<HTMLElement>)
        .filter(el => isInlineWithStyle(window.getComputedStyle(parentHTMLElement), el))```
    ... 

[mindplay-dk]

@yortus hmm, introducing an arbitrary variable as a work-around... stuff like that raises questions for someone reading it - like, if I were to see something like that, my immediate inclination would be to factor away a useless intermediary variable... ugly in deed :-/

[yortus]

@mindplay-dk yeah it's a smell, and it's not the only place you need to add a superfluous variable to make type inference happy. But in this case at least, I can't imagine how tsc could infer that it's safe to narrow inside the function expression without god-like knowledge of the runtime behaviour of the code.

Maybe in your case it's cleaner to just use an explicit type assertion, i.e. <HTMLElement> parentElement, inside the function expression.

[mindplay-dk]

@yortus thanks, a type assertion - yes, that's cleaner :-)