Оператор in

type Cat = {
  meow: () => void
};

type Dog = {
  bark: () => void
};

export function speak(animal: Cat | Dog): void {
  if ("bark" in animal) {
    animal.bark();
  } else {
    animal.meow();
  }
}

В ветке if тип сужен до Dog, в else до Cat. Оба вызова легальны, и оба теста проходят.

Почему не typeof и не instanceof

typeof animal вернёт "object" и для кота, и для собаки, различить их так нельзя. instanceof работает с классами и их прототипами, а здесь обычные объектные литералы, никаких классов нет. Остаётся проверка по форме, и in подходит для неё лучше всего.

Иногда пишут проверку на существование метода напрямую:

if (typeof (animal as Dog).bark === "function") { }

Это работает, но требует приведения типа и читается хуже. in сужает тип сам.

Проверять лучше уникальное свойство

Сужение через in опирается на то, что свойство встречается ровно в одном варианте union. Если добавить третий тип, у которого тоже есть bark, проверка перестанет однозначно указывать на Dog, и в ветке окажется объединение из двух типов.

Что делать, когда вариантов много

Проверки по разным свойствам плохо масштабируются: три типа это уже цепочка из нескольких in, и легко забыть ветку. Для таких случаев есть более надёжный приём: добавить всем вариантам общее поле-метку и различать их по значению этого поля. Это дискриминированное объединение, финальное задание курса.

in и опциональные поля

Стоит помнить, что in проверяет наличие ключа, а не значения. Если поле объявлено необязательным, ключ может присутствовать со значением undefined, и проверка окажется истинной:

const dog = {
  bark: undefined
} as unknown as Dog;

"bark" in dog; // true, хотя вызывать нечего

С формами, где свойства обязательные, как в этом задании, такой проблемы нет.