Как влияют неявные преобразования типов в JavaScript на разработку

Что проверяют

Понимаете ли вы, где приведение типов помогает, а где создаёт трудноуловимые ошибки, и как от него защищаются.

Как отвечать

JavaScript приводит типы почти в любой операции, где они не совпадают. Иногда это удобно, чаще это источник ошибок, которые не падают, а тихо дают неверный результат.

Классические примеры:

"5" + 3      // "53": плюс склеивает, если один операнд строка
"5" - 3      // 2: минус приводит к числу
[] + {}      // "[object Object]"
0 == ""      // true
NaN === NaN  // false

Отдельно приведение к логическому: ложными считаются false, 0, -0, "", null, undefined, NaN, всё остальное истинно, включая пустой массив и пустой объект. Отсюда классическая ошибка: if (arr.length) работает, а if (arr) истинно всегда.

Как с этим живут на практике:

• строгое сравнение === везде, кроме идиомы == null;
• явное приведение: Number(x), String(x), Boolean(x) вместо +x и !!x, потому что читается однозначно;
• ?? вместо || для значений по умолчанию, иначе ноль и пустая строка подменятся;
• валидация на границе: данные из формы, адреса и JSON.parse приходят строками и неизвестной формы;
• TypeScript снимает часть проблем на этапе компиляции, но в рантайме приведение остаётся тем же.

Где спотыкаются

Складывают значение из поля ввода с числом и получают склейку строк.

Проверяют if (value) там, где ноль это допустимое значение.

Используют || для значения по умолчанию.

Считают, что TypeScript отменяет приведение типов во время выполнения.