большое приложение на чистом js (react, redux все дела)
- приложение разбито на модули, которые собираются каждый своим конфигом вебпака
- есть желание написать новый модуль на ТСе. модуль практически изолирован и по большому счету зависит только от библиотеки UI (которая не на ТСе)
вопросов два
- стоит ли вообще использовать ТС при нетипизированном бекенде?
- если стоит, то какой от него конкретный бенефит?
Зависит от модуля. Конкретно для модуля это может быть профит. Для всего приложения - может быть провал
а в чем профит для модуля, если бек все равно не покрыт? только "межкомпонентное" общение?
Защита модуля от неопределённых изменений в других частях приложения
ясно. ок, спасибо
Отпишитесь, что выбрали. Интересно же)
если выберем тс, я тут буду частым гостем 😂
Добро пожаловать. Польза от тс может быть настолько очешуительна, что рассказывать придётся неделю. Поэтому на этот вопрос отвечать не буду. А нетипизированный бэк можно прикрыть валидатором и работать внутри приложения так, будто бэк типизированный
А можно чуть подробнее про валидатор? Буквально два слова, куда и где посмотреть
Контракты, yup, zod, io-ts https://t.me/ts_cool/136888 и ниже
❤️
«Стоит ли использовать ТС при нетипизированном бэкенде» Стоит. Скорее всего у твоего бэка есть все же определенные структуры у запросов и ответов. Я не очень понимаю что значит «нетипизированный бэкенд» в этом контексте. У вас просто доков нет? «Какой профит?» Профитов от тайпскрипта уйма. Ты получаешь самодокументируемый код, который парсится твоим редактором, который в свою очередь следит, чтоб ты не сделал глупых ошибок. Огромная часть проблем отсекается ещё на этапе написания кода.
Обсуждают сегодня