Отделите описание от фактического значения
Пусть приложение ожидает объект с полем количества, содержащим целое неотрицательное число. Описание такого типа сообщает разработчику и компилятору, какие значения предполагаются. Но внешний источник может прислать текст, пустое значение или объект без нужного поля. Утверждение типа через as не исправляет содержимое и не добавляет автоматическую проверку во время работы программы. Оно сообщает компилятору выбранное предположение, поэтому не должно служить заменой проверки недоверенных данных.
Успешный разбор JSON ещё не проверяет схему
JSON.parse преобразует корректный текст JSON в значение JavaScript. Синтаксическая ошибка и несоответствие бизнес-правилу являются разными проблемами. Корректный ответ может содержать строку вместо числа или число минус один, хотя наш пример запрещает отрицательное количество. Поэтому после разбора требуется проверить форму результата, наличие поля, тип значения и допустимые ограничения. Для нашей модели положительная дробь тоже не подходит: речь идёт о целых единицах. Для другой задачи допустимые значения могли бы отличаться.
Сужайте неизвестное после проверки
Тип unknown помогает обозначить, что о входном значении пока недостаточно известно. Перед использованием требуется уточнение через реальные проверки. Проверка typeof полезна, но имеет особенности: пустое значение null тоже даёт результат object. Если ожидается обычная запись, нужно отдельно исключить неподходящие варианты, включая массив. Затем проверяют поле количества. Для проверки целого числа существует Number.isInteger, однако условие неотрицательности задаётся отдельно. Не следует молча превращать неверное значение в ноль, если такого правила нет в требованиях.
Продумайте поведение при ошибке
При несоответствии данных приложение должно выполнить заранее определённое действие: показать понятное сообщение, пропустить непригодную запись по согласованному правилу или остановить обработку. Выбор зависит от задачи. В нашем учебном варианте неверная запись не считается товаром с нулевым остатком. Иначе техническая проблема станет выглядеть как достоверное отсутствие товара. Проверяйте не только успешный ответ, но и пропущенное поле, неправильный тип и значение за границей допустимого. Такие случаи помогают проверить смысл проверки, а не только отсутствие ошибки компиляции.
Попробуйте на практике
Составьте бумажную таблицу проверки вымышленного поля количества без запросов к серверу и без запуска приложения.
- Определите правило: значение должно быть числом, целым и неотрицательным. Запретите неявное преобразование текста в число.
- Запишите пять примеров: число три, число ноль, число минус один, дробь полтора и текст из цифры три.
- Для каждого примера укажите, какое условие выполнено или нарушено. Отдельно добавьте случай отсутствующего поля.
- Опишите сообщение об ошибке и убедитесь, что неправильное значение не заменяется нулевым остатком без согласованного основания.
Как проверить результат. Числа три и ноль принимаются; отрицательное число, дробь, текст и отсутствие поля отклоняются по заданной модели. Утверждение типа не названо проверкой фактических данных.
Частые вопросы
Зачем TypeScript, если нужны дополнительные проверки?
Он помогает проверять согласованность кода и использовать уже проверенные значения с понятными типами. Контроль внешнего ввода дополняет эту работу на границе, которую статическое описание само не проверяет.
Можно ли разрешить строку с числом?
Можно определить отдельное явное правило преобразования, если это соответствует требованиям. Тогда нужно описать допустимый формат и обработку ошибок. Само наличие цифры в тексте не должно незаметно менять правила модели.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.