ER
а я вообще не понимаю зачем фронту валидировать данные бека. Это проблема бека если он отдал не ту структуру которую декларировал
Size: a a a
2020 April 13
ER
достаточно писать тесты для бека
EC
достаточно писать тесты для бека
+
EC
Так проверки, которые якобы можно не писать с TS, не писать нельзя, потому что они как раз для проверки данных в рантайме. Короче твоя фраза явно подсветила проблему.
Подсветила проблему неуверенности в бекенде. Это явно проблема не фронта.
PM
Подсветила проблему неуверенности в бекенде. Это явно проблема не фронта.
Ошибки то будут на фронте
EC
если бекенд вернул говно. то на фронте в любом случае будет говно
PM
если бекенд вернул говно. то на фронте в любом случае будет говно
Бекенд может не вернуть говно, он просто измерялся. И никакой ТС не поможет выявить что где-то фронт ожидает устаревшие типы/формат данных
ER
как я вижу идеальный пример, это когда бек разработчики генерируют ts описание типов реквестов и респонсов для своих апи, а фронт их просто используют.
PM
Частично эта проблема решается в GQL с помощью сквозной типизации
PM
как я вижу идеальный пример, это когда бек разработчики генерируют ts описание типов реквестов и респонсов для своих апи, а фронт их просто используют.
Собственно примерно это и делается в GQL
PM
Но опять же тогда бекенд должен быть фактически контролируемым. Часто это бывает не так ( бекенд старый, чужой, разработан другой командой или даже компанией, итп)
PM
Например мы пишем в основном клиентские приложения на чужих бекендах, реже делаем все с нуля сами, поэтому смысла в TS ооочень мало, а ложная уверенность, которую он даёт, может лишь усугубить ситуацию. Мы вынужденны писать ассерты и только так можем быть уверены в данных
ER
тогда все от проекта зависит. у меня сейчас наш бек и единственная проблема что мне часто приходится открывать свагер и смотреть ту структуру которую возвращает сервер. И тут мне бы заглаза хватило описания типов, просто как документация для удобства разработки
A
А свагер - это что?
СА
А свагер - это что?
документация к апи
IF
Например мы пишем в основном клиентские приложения на чужих бекендах, реже делаем все с нуля сами, поэтому смысла в TS ооочень мало, а ложная уверенность, которую он даёт, может лишь усугубить ситуацию. Мы вынужденны писать ассерты и только так можем быть уверены в данных
Не обязательно TSом обмазываться с ног до головы. Кому-то достаточно и простой типизации на клиенте. Благо TS настраиваемый и позволяет постепенно или частично внедрить его в проект. К пример для удобства разработки (подсказки в ide и т.п.).
Хотя ты и так это знаешь...
Хотя ты и так это знаешь...
IF
А свагер - это что?
Вот пример: https://petstore.swagger.io
A
Спасибо всем
T
тогда все от проекта зависит. у меня сейчас наш бек и единственная проблема что мне часто приходится открывать свагер и смотреть ту структуру которую возвращает сервер. И тут мне бы заглаза хватило описания типов, просто как документация для удобства разработки
иногда достаточно jsdoc`ом описать функции, vscode их автоматом подсвечивает например
ДЧ
так а что не так то