API parameters should be camelCase, rather than snake_case

[makenotion]

API parameters should be camelCase, rather than snake_case

[kud]

Hello!

I understand now why you used snake_case, as the API is written like this. However, a js client should be an abstraction and also respects the consistency / convention of a language.

I already did a js client for a json:api api which were in snake_case. I did an helper for that wwith https://github.com/blakeembrey/change-case where it transforms any params for the post request or even for the result of the query. Like that, the dev hasn't any issue to understand how to use/write their code.

So yeah, everything should be in lowerCamelCase for the JS Client and you add a little helper to convert everything.

[aoberoi]

Thanks for the feedback! I know its a little odd, but we intentionally chose snake_case for all API parameters, and chose lowerCamelCase for client-specific API.

The reason is that the JSON-formatted body parameters already have snake_case property names, so in a method call that makes an API request a single object with mixed casing would look really odd. We could have made the whole package only use snake_cased symbol names for consistency, but that also felt like it would conflict most of the JS ecosystem (for example, built-ins like Array.prototype.forEach()). So this compromise is where we ended up.

Would you rather see databaseId next to something like start_cursor in an object? Do you have a different proposal?

[cwang314]

Hi @kud , thanks for the SDK feedback; I've gone ahead and added this to our internal tracker. Truthfully, we probably won't get to this for a while - we're working on improving/enhancing the existing API and there's a decent amount of work to improve types and usability before addressing snake_case vs. camelCase.

We don’t actively monitor the issues in this repo, but in the future you can submit feedback by emailing us at [email protected].

[kud]

seems legit, thank you @cwang314 !