APIs: camelCase, snake_case and dot-notation

[andrewdeandrade]

It's not uncommon to make requests to an API that returns a JSON object with keys that are not in camelcase (especially if the API is written by pythonistas or people from any other community that prefers snake_case).

In this scenario, you will often find yourself accessing a property that results in linting warnings for the camelcase rule.

Some thoughts on this:

• Is there any way through static syntax tree analysis to determine when a key is from an API, thus is data and should be okay?
• keys from APIs represent unminifiable tokens. Google Closure compiler has a mode that allows you to squeeze out more compression without breaking APIs so long as you take API data keys and express them in bracket notation. By using bracket notation, the string becomes an incompressible value, and this allows the minifier to minify everything else without risk of minifying property keys that should not be compressed.

I don't really have a good idea yet how this use case might be addressed by eslint trap, so I'm curious what others are doing in this scenario.

• Are people disabling camelcase as an error in projects where this happens or are you doing a deep clone of snake_case API data to a new object with camelCase keys?
• Doing something else?

[nzakas]

This doesn't appear to be a bug report or a request for a change, so closing. Please use the mailing list for general questions.

Fwiw, in my own projects I just disable camel-case around the API response.

[andrewdeandrade]

Sorry. Will post to the google group.

[tschaub]

@malandrew not sure what sort of response you got, but my proposal is to add an allowSnakeCase option to the dot-notation rule (see #1679).

[andrewdeandrade]

That rule sounds good so long as there is an option for only applying it to property access. i.e. Function calls (methods or library functions) would still need to adhere to camelCase

Good:

var fname = data.first_name;

Bad:

var fname = user.get_first_name();