Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inflectKeys behaviour on camelCase attributes #51

Open
JohnField opened this issue Oct 11, 2017 · 1 comment
Open

inflectKeys behaviour on camelCase attributes #51

JohnField opened this issue Oct 11, 2017 · 1 comment

Comments

@JohnField
Copy link

Hi, the README states

inflectKeys: camelize the field names per record. Default: true.

However, we've found that if the recordType attribute is already camelCase (e.g. phoneNumber ), it's transformed to phone-number via e.g. https://github.com/fortunejs/fortune-json-api/blob/2.1.2/lib/helpers.js#L213 ) so have set inflectKeys:false to preserve them , which makes the README seem misleading.

What's the intended behaviour for camelCase'd attributes?

@gr0uch
Copy link
Member

gr0uch commented Oct 11, 2017

Oops, it seems the README is misleading, or at least only describes one direction. It is true that it camelizes field names from the request body when creating or updating records. But it also dasherizes field names on output. That's why it's called inflectKeys and not camelize/dasherize.

  • Fields on a record type should follow JS convention of camelCase in JS code, nothing unusual here.
  • Over the wire, it should use dasherized-attributes per the JSON API recommendation.

Member names SHOULD contain only the characters “a-z” (U+0061 to U+007A), “0-9” (U+0030 to U+0039), and the hyphen minus (U+002D HYPHEN-MINUS, “-“) as separator between multiple words.

I don't make those recommendations, and would have liked it if they made it less confusing.

I'd appreciate a PR to fix the README!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants