Next.js, общий тип Id и union-состояния
Одна из полезных мыслей про TypeScript в Next.js: типы ценны не внутри компонента, а на границах. Например, когда есть общий тип Id для сущности. Или когда результат операции описан как union, а не как набор флагов. TypeScript начинает работать не как декоративная надстройка, а как защита от неправильных состояний Практический эффект приземлённый. Сырой ввод из URL не уходит сразу в доменный слой. UI не пытается одновременно жить в success и error. Ошибки чинятся через контракт и guard-логику, а не через подавление сигнала. Здесь хорошо видно, зачем TS вообще нужен в App Router. Не ради строгости, а ради устойчивости между server, client, URL, store и UI.
Подробный разбор сделал в статье на Хабр Проект с примером: Workbench Stepik: Next.js II: TypeScript 2026
· 21.04
про "типы ценны на границах" - в python эта же идея через pydantic: вместо того чтобы валидировать внутри функции, создаёшь входной тип и fastapi автоматически проверяет на входе. интересно что к этому паттерну приходят и в ts и в python - разные языки, одна и та же логика про точки входа
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 21.04
Да, логика действительно похожая. В обоих случаях полезный сдвиг в одном месте, проверка и нормализация выносятся на вход, а внутренняя логика дальше работает уже не с сырым значением, а с контрактом. В TS это жёстче, потому что типовая граница начинает влиять на весь проект сразу, включая сборку и деплой. В Python помню это больше дисциплина вокруг входных данных, а не как стальная сетка по всему коду. Но архитектурно то же, не размазывать проверки внутри каждой функции, а собирать их у точки входа
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён