Hacker News new | ask | show | jobs
by int_19h 478 days ago
> The playground hover type annotation says aOrB is `A | B` at declaration and if you hover over aOrB in `if (hasTypeName(aOrB, "A"))` it produces `const aOrB: B`. Two types for 1 variable with no operations between.

It's not that the variable has two different types. It's that the expression `aOrB` has a different type inside the condition. This is normal for TS - indeed, the very pattern of doing a check first and then magically getting a different type inside the body of the conditional hinges on this narrowing behavior. This particular case just looks a bit weird because there's no conditional, it's based solely on the assignment. You can see the same in code without any conditionals at all:

  let foo: {foo: number} | {bar: string};
  foo = {foo: 123};
  foo; // if you hover over foo here, the type is narrowed.
So, before it even gets to the type guard, it has already determined that the actual type of expression `aOrB` can only be `B`, and typed it as such. OTOH when a type guard is used, if it returns true, it knows that `aOrB` can only be `A`. To combine these two, it has to type it as `A & B`, which is what you see in the hover if you do it inside the body of the conditional. And the intersection type will only show the properties `A` and `B` have in common.

As for your new example, keep in mind that a missing property is not the same as `undefined` in TS (nor in JS itself, since there are ways to observe that difference). So the sum type must have both `a` and `b`, but either one can be set to `undefined` (but not omitted!) depending on `type`. If you remove `b: undefined` from the initializer of `aOrB`, you will see an error telling you that `b` is missing.

However, your example does not produce any error at the line with the comment that says "Error". Instead, you get a warning on the line above, specifically for this expression:

   aOrB.type.name === "B"
And if you look at the text of that warning, it basically says that `aOrB.type.name` is statically known to always be of type "A" at this point (since that is what was in your initializer, and TS did the requisite narrowing), and thus comparing it to "B" is pointless since it'll never be equal. All the property accesses for `a` and `b` work fine though since your sum type has both properties for both variants.