Рендер и доводка настроек

Доска задач из части II перерисовывалась целиком из массива: данные решают, разметка отражает. Каталог устроен так же, но карточка теперь собирается из полей Product, и каждое имя на этом пути проверено.

interface Product {
  readonly id: string;
  title: string;
  price: number;
  inStock: boolean;
}

const catalog: Product[] = [
  { id: "p1", title: "Кофемолка", price: 4990, inStock: true },
  { id: "p2", title: "Турка", price: 1290, inStock: false }
];

// узел собирается из полей записи, а не из строки: имена полей проверены,
// а содержимое кавычек компилятору безразлично
function cardOf(product: Product): HTMLElement {
  const card = document.createElement("article");
  card.dataset.id = product.id;
  const title = document.createElement("h3");
  title.textContent = product.title;
  const price = document.createElement("p");
  price.textContent = product.inStock ? product.price + " руб." : "нет в наличии";
  card.append(title, price);
  return card;
}

document.body.append(...catalog.map(cardOf));
console.log(catalog.map((product) => product.title).join(", "));

Тип HTMLElement у cardOf написан для читателя — компилятор вывел бы его сам. А вот createElement знает больше, чем кажется: createElement("input") отдаёт HTMLInputElement со всеми его полями, а createElement("article") — просто HTMLElement, потому что своего интерфейса у этого тега нет.

Проверка имён — не абстрактная польза. Опечатка в поле не ломает страницу: карточка соберётся и будет спокойно врать.

interface Product {
  readonly id: string;
  title: string;
  price: number;
  inStock: boolean;
}

const product: Product = { id: "p1", title: "Турка", price: 1290, inStock: true };
const badge = document.createElement("p");
badge.textContent = product.stock ? "в наличии" : "нет в наличии";
document.body.append(badge);
console.log(badge.textContent);

product.stock — это undefined, undefined ложно, и товар в наличии показан как отсутствующий. Компилятор находит это до запуска и даже подсказывает верное имя: «Свойство "stock" не существует в типе "Product". Вы имели в виду "inStock"?».

Соберите ту же карточку строкой через innerHTML — и проверка исчезнет: внутри кавычек компилятор не читает ничего, там снова просто текст.

querySelector объявлен как Element | null — и это первая настоящая ссора с DOM: вы-то знаете, что #catalog в разметке есть.

const root = document.querySelector("#catalog");
root.append("каталог на месте");
console.log(root.textContent);

Две диагностики — и работающая страница. Выполнение они не отменили: типы стираются, и tsc по умолчанию выпускает код даже с ошибками. Но придирки здесь нет. Разметку компилятор не читал и читать не может: поменяется вёрстка, переименуется идентификатор, шаблон соберётся по-другому — и null станет реальностью. С ?. такая опечатка даже не упадёт, а молча ничего не нарисует.

Поэтому узел, без которого рендер бессмыслен, разумно требовать громко — один раз, на старте.

// узел, без которого рендер бессмыслен, требуем громко и один раз:
// падение на старте понятнее, чем пустой экран без единой строки в консоли
function mustFind<E extends Element>(selector: string): E {
  const node = document.querySelector<E>(selector);
  if (node === null) throw new Error("в разметке нет " + selector);
  return node;
}

const list = mustFind<HTMLUListElement>("#list");
const item = document.createElement("li");
item.textContent = "Кофемолка";
list.append(item);
console.log(list.children.length);

Тип E у mustFind выбирает вызывающий, и никто его не проверяет — та же ловушка дженериков, что в главе про них: подпись удобная, а ответственность на вас.

const byTag = document.querySelector("input");
console.log(byTag?.value);

const byId = document.querySelector("input#search");
console.log(byId?.value);

Обратный путь начинается с делегирования — одного обработчика на контейнере, как на доске задач в части II. Только теперь между кликом и записью каталога стоят три типа, и каждый требует ответа.

document.body.addEventListener("click", (event) => {
  const card = event.target.closest("[data-id]");
  console.log(card === null ? "мимо каталога" : card.tagName);
});

document.querySelector("button")?.click();

«Свойство "closest" не существует в типе "EventTarget"» звучит странно ровно до того момента, как вспомнишь: target — не элемент. Событие приходит и от window, и от XMLHttpRequest, и от любого объекта, умеющего принимать события; общий контракт EventTarget знает только про подписку и отправку.

interface Product {
  readonly id: string;
  title: string;
}

const catalog: Product[] = [
  { id: "p1", title: "Кофемолка" },
  { id: "p2", title: "Турка" }
];

document.body.addEventListener("click", (event) => {
  if (!(event.target instanceof HTMLElement)) return;
  const card = event.target.closest<HTMLElement>("[data-id]");
  if (card === null) return;
  const id = card.dataset.id;
  const product = catalog.find((item) => item.id === id);
  console.log(product === undefined ? "клик мимо каталога" : product.title);
});

document.querySelector("button")?.click();

Ступеней ровно три, и ни одна не лишняя. instanceof HTMLElement сужает EventTarget | null до элемента — тот же приём, что в главе про сужение. closest отдаёт Element | null: карточки над кликом может не быть вовсе. А dataset — это DOMStringMap с индексной сигнатурой, поэтому card.dataset.id имеет тип string | undefined, и find следом честно возвращает Product | undefined.

closest<HTMLElement> — утверждение в маске дженерика: компилятор поверит на слово. Если карточкой может оказаться что угодно, надёжнее ещё один instanceof.

Пока каталог писался с нуля, строгость не мешала: код рождался уже с типами. Но в проект приезжает чужое — функции из части II, наброски из консоли, кусок соседнего модуля. Строка "strict": true включает восемь проверок разом (в главе про настройку они разобраны по одной), и на готовом коде всплывают три класса диагностик.

interface Product {
  readonly id: string;
  title: string;
  price: number;
}

const catalog: Product[] = [
  { id: "p1", title: "Кофемолка", price: 4990 },
  { id: "p2", title: "Турка", price: 1290 }
];

// функция переехала из части II, где типов не было вовсе
function labelOf(product) {
  return product.title + " — " + product.price + " руб.";
}

console.log(labelOf(catalog[0]));

Первый класс — неявный any. Функция работает и печатает что надо; компилятор всего лишь отказывается угадывать, что ей передадут. Одна аннотация product: Product убирает диагностику и заодно включает проверку полей внутри функции.

interface Product {
  readonly id: string;
  title: string;
}

const catalog: Product[] = [
  { id: "p1", title: "Кофемолка" },
  { id: "p2", title: "Турка" }
];

const found = catalog.find((item) => item.id === "p9");
console.log(found.title);

Второй класс — то, чего может не быть. find объявлен как Product | undefined, и это не формальность: товара p9 в каталоге нет, и на запуске код падает ровно там, куда показал компилятор. Такой пример полезно досмотреть до конца: сначала диагностика, потом TypeError — одна ошибка, пойманная дважды.

try {
  JSON.parse("{нет такого");
} catch (err) {
  console.log("каталог не разобран: " + err.message);
}

try {
  JSON.parse("{нет такого");
} catch (error) {
  // unknown заставляет спросить, что поймали, — а не считать это ошибкой по умолчанию
  const reason = error instanceof Error ? error.name : "не Error";
  console.log("каталог не разобран: " + reason);
}

Порядок доводки скучный и рабочий: включили — починили всё, что всплыло, — закоммитили. Если код большой, а времени мало, strict разбирается на отдельные флаги: noImplicitAny первым, strictNullChecks следом — он даёт самый длинный список и самую большую пользу.

Строгость — не потолок. В каталоге после неё остаются три дыры, и все три видны на запуске.

interface Product {
  readonly id: string;
  title: string;
}

const byId: Record<string, Product> = {
  p1: { id: "p1", title: "Кофемолка" },
  p2: { id: "p2", title: "Турка" }
};

console.log(byId["p1"].title);
console.log(byId["p9"].title);

Record<string, Product> обещает Product по любой строке: компилятор верит объявлению, а не содержимому объекта. Дыру закрывает флаг noUncheckedIndexedAccess из главы про настройку, но есть способ и без флагов — коллекция, у которой честный тип написан прямо в подписи.

interface Product {
  readonly id: string;
  title: string;
}

const byId = new Map<string, Product>([
  ["p1", { id: "p1", title: "Кофемолка" }],
  ["p2", { id: "p2", title: "Турка" }]
]);

console.log(byId.get("p9").title);

Вторая дыра — as. Утверждение выключает проверку в одной точке, и достаточно перевесить идентификатор на обёртку, чтобы обещание перестало быть правдой.

// разметку поменяли: поле обернули в контейнер, и id переехал на обёртку
const search = document.querySelector("#search") as HTMLInputElement;
console.log(search.value.trim());

Компилятор молчит: вы сказали ему, что это HTMLInputElement, — он поверил. В рендере такие утверждения заводятся чаще всего, потому что as HTMLInputElement — самый быстрый способ закрыть Element | null и не думать.

Третья дыра — сами данные. Типы описывают то, что вы обещали, а не то, что пришло: каталог с сервера остаётся unknown, пока его не разобрали проверками, — этим мы занимались в начале главы. К рендеру модель уже проверена, и Product[] здесь не предположение, а результат.

Редактор показывает ошибки только в открытых файлах — поэтому команда проверки в package.json нужна даже одиночке: она смотрит на весь проект сразу и говорит «зелено» одним ответом.