а приложение использует везде camelCase, нормально ли хранить два идентичных типа под разные стили?
Я нагуглил, что TS умеет по сути обрабатывать типы, т.е. можно описать snake_case тип, а потом просто написать аля
camelCaseType = snakeToCamel<snakeCaseType>
чтоб не дублировать типы. Понятно, что snakeToCamel еще нужно создать
В общем вопрос – как вы такое хендлите на своих проектах?
у нас маппили имена полей после валидатора туда-сюда =)
Я так на js проектах делал. Аля была просто функция, которая мапила значения. Точнее не функция, а класс, но то уже другое дело. Но теперь ведь есть TS, нужно как-то оправдывать его наличие
ts не для рантайма
Та мне на рантайм плевать Пусть будет какая-то функция, аля что я написал, которая на стадии компиляции создаст мне тот же тип для респонса, только camelCase Ну и всякие там автокомплиты/подсветочки чтоб работали
я два типа храню
Не надоедает поддерживать в актуальном виде?
https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#template-literal-types
Ну и просто «многокода» ведь
нет, наоборот удобно, сразу видно разделение что для бэка, что для фронта
А какой у вас стиль именования? Просто camelType/snakeType?
у меня везде camel, я же фронт
Я скорее о том, как вы именуете одинаковые типы, у которых разница только в camel/snake кейсе?
Хах, ну это понятно 🙂 Аля CamelUserInfo + SnakeUserInfo?
UserInfo - BackendUserInfo
Воо Ну, в принципе имеет смысл, наверное Спасибо за информацию 🙂
там различие не в кейсе в основном, иногда переименовываю поля как мне удобнее, иногда структуру меняю
Обсуждают сегодня