Как быть с camelCase на фронте и snake_case на бэкенде?

Question

[lavezzi1]

Вопрос в следующем, на фронте используем camelCase во всем. Но когда с бэкэнда прилетют данные в виде:

{ first_name: 'First', last_name: 'Last', is_admin: false, is_premium: true, avatar_url: 'some-url' }

и например, часто нужно данные дублировать и изменить, например добавить какие то поля и так как на фронте используется camelCase, то поле будет выглядеть так: isDeleted: true. Выходит некрасивая картина.

Я вижу два выхода из этой ситуации: 1) Использовать snake_case на фронте при добавлении новых поле; 2) Использовать какую-нибудь библиотеку которая будет переводить все данные к camelCase стилю.

Как быть?

Comments

[Adamos]

какую-нибудь библиотеку которая будет переводить все данные к camelCase стилю.

Библиотеку? Одна функция - создать новый объект, пройти по полям исходного, добавить новому те же поля, но с заменой "подчеркивание-буква" на "заглавная буква". Вот и вся "камелизация". Если у вас данные с бэка и так проходят через какую-нибудь общую функцию (что полезно, например, для единообразного отображения ошибок), то просто добавить туда этот код.

Answer 1

[Василий Мажекин]

Если бекендер очень высокого уровня, то есть умеет красиво и оптимально проектировать методы и данные под потребности клиентских app, четко это документировать (swagger) и покрывать тестами свои методы, то обычно таких проблем не возникает.
В противном случае контролируйте все что приходит с бекенда, сделайте статические мапперы, подстраиваться под бек не вариант, всякие линтеры начнут ругаться, вы начнете запутыватся в плохоименованных переменных, уговаривать бекендеров слать данные в нужном формате то же больше времени потратите, третий вариант сам приемлемый, бекенд часто шлет, не то что в нужном формате а еще много того что не нужно на фронт.
Например: бекенд шлет (это частая ситуация, так в бд например хранится, а правила кодирования у разных клиентов (web, ios, android) свои, но они могут использовать один и тот же бек)

{
  ID '2342',
  stu_cfg: 'werwer'
  pfu_num: '1231'
  sys_created: '2000-12-10'
  register_date: '06 Mar 2017 21:22:23 Z'
}

бы обозначаете что вам нужно и в каком виде (в тайпскипте например) (или в js комментариями)

interface SomeEntity {
  id: string,
  status: string,
  created: Date
  registered: Date 
}

class MyMapper {
    static someEntityToClient(data): SomeEntity {
        const someEntity: SomeEntity = {
           id = data['ID'],
           status = data['stu_cfg'],
           created = moment(data['sys_created']).toDate
           registered = moment(data['register_date']).toDate 
        }
        return someEntity;
    } 
}

И вызовите маппер сразу после апи вызова как только получили данные. Таким образом вы решите проблемы:
1) ненужные данные отфильтруете, чтоб не ломать голову (что это? зачем?) потом во время отладки фронта
2) в коде будет единый стандарт именования переменных (плюс закодированные имена (cfg, klk и т. п.) пропишете понятно).
3) в бизнес логике будет единый стандарт типов данных (как например со временем) (преобразований не надо потом нигде по 10 раз делать, проверки отпадут, вы все проконтролировали на входе)