What about camelCase on the front and snake_case on the backend?

Question

JavaScript

The question is, on the front we use camelCase in everything. But when data arrives from the backend in the form:

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

and for example, you often need to duplicate and change data, for example, add some fields, and since camelCase is used on the front, the field will look like this: isDeleted: true . An ugly picture emerges.
I see two ways out of this situation: 1) Use snake_case on the front when adding new fields; 2) Use some library that will translate all data to camelCase style.
How to be?

Answer 1

If the backender is of a very high level, that is, it can beautifully and optimally design methods and data for the needs of client applications, clearly document it (swagger) and cover its methods with tests, then usually there are no such problems.
Otherwise, control everything that comes from the backend, make static mappers, adjusting to the backend is not an option, all sorts of linters will start to swear, you will start to get confused in poorly named variables, persuade backenders to send data in the right format, spend more time, the third option is acceptable, the backend often sends, not only in the right format, but also a lot of things that are not needed for the front.
For example: backend sends (this is a common situation, for example, it is stored in the database, and different clients (web, ios, android) have their own encoding rules, but they can use the same backend)

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

would indicate what you need and in what form (in typeskip for example) (or in js with comments)

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;
    } 
}

And call the mapper immediately after the api call as soon as the data is received. This way you will solve the problems:
1) filter out unnecessary data so as not to rack your brains (what is it? why?) later while debugging the front
2) there will be a single variable naming standard in the code (plus encoded names (cfg, klk, etc.) ) write clearly).
3) in business logic there will be a single standard of data types (as, for example, over time) (then you don’t need to do transformations anywhere 10 times, checks will disappear, you checked everything at the input)