Support lowerCamel key format #534

merged 2 commits into from Jul 28, 2014


None yet

You can specify that serializers use the lower-camel key format at the config, class or instance level.

ActiveModel::Serializer.setup do |config|
  config.key_format = :lower_camel

class BlogLowerCamelSerializer < ActiveModel::Serializer
  format_keys :lower_camel
end, key_format: :lower_camel)

Relevant to issue #398. Pull request #436 also offered a solution for changing the key format but that approach is now in conflict with head/master.


This is working great for me, thanks!

I don't know if it was something you wanted to address with this PR but the root element key is not camelized.


How is this PR going? I think it's a very useful feature for AMS to have, seeing that most JS frameworks don't help to do key conversions without going through a big loop



I've been using this branch for a couple of weeks and it works fine. Two things I noticed, that should be fixed are:

One - if you inherit from a base serializer in which you've set the key format, that information is lost and you need to call format_keys again.

class ApiSerializer < ActiveModel::Serializer
  format_keys :lower_camel

class ThingSerializer < ApiSerializer
  # doesn't respect the key_format defined in the base class

Two - root keys for side loaded relationships do not respect the key format.

class ThingSerializer < ActiveModel::Serializer
  has_many :other_things

class OtherThingSerializer < ApiSerializer
  # the key will be other_thing instead of otherThing

But really, and more importantly, it's been 3 months since any PR been accepted on this repo. It sort of feels a little under supported.


What's the status of the pull request? I'm working on something that would benefit from this and would like to know if it's something that has a chance of being included in AMS proper.

@steveklabnik steveklabnik merged commit 045ba2a into rails-api:master Jul 28, 2014

1 check passed

Details continuous-integration/travis-ci The Travis CI build passed

Thank you for this pull request, and I'm sorry it took so long to make it in. Ember people will be very happy with this. :)


This is not working on v0.10.0.rc1. Was it removed?

rails-api member

Hey @zavan actually it wasn't implemented on 0.10 version. 😄


Thanks @joaomdmoura. Will it be implemented?

rails-api member

@zavan we haven't talked about it yet.
When it was implemented it made sense because of ember.js. But, as far as I know, Ember is also updating its format to use JSON API (that 0.10.0 currently supports).
Do you have a particular need related to it?


I implemented this feature to support javascript frameworks in general (not specifically ember).

If you're working with serialized data from javascript, it makes sense to use the key naming format for that language.

rails-api member

I know @kylefritz 😄 I just was pointing out that back than it make ember integration simpler.

We haven't received a lot of requests related to it and we are deeply focus on make this integration with Rails 5 happen. But if you want, you can open a PR bringing this feature to 0.10 we would definitely check it 😄


cool. we're locked on an older AMS version. I'll drop in a new PR soon-ish. good luck with the rails 5 integration.


would be great to have this working in 0.10 👍


@zavan i totally agree about the inheritance. i'm not sure why that never worked.

i also had an issue getting the "top-level" key to be formatted correctly. for example

#some controller
render json: important_things, serializer: ImportantThingSerializer


{important_things: [{correctlyFormattedKey: true}, {correctlyFormattedKey: true}..]}

I'll see if I can re-implement this method against the 0.10 branch. Suggestions welcome.

rails-api member

@kylefritz just a heads up, the PR #958, that will probably be merged soon, will change how the root is implemented right now, so you should wait for it to be merged to work on top of it in case you really want to move forward with this PR.


oh great info @joaomdmoura. thanks for the heads up.


I'm using the JSON API adapter with ember-data and I'm having a small compatibility issue.
Attributes generated by AMS are using underscores (as they are left untouched), while ember-data/jsonapi uses the dasherize function for the attribute lookup.

The jsonapi spec does not mention anything about word separators, but the examples do use dashes.

Should this transformation be handled specifically by the jsonapi adapter? Or should AMS provide a general way of applying key transformations?

My current workaround was to define a base serializer:

class BaseSerializer < ActiveModel::Serializer
  def attributes *args
    Hash[ do |key, value|
      [key.to_s.dasherize.to_sym, value]
rails-api member

hey @hugopeixoto,
just checked with json api folks.

dashes are just a recommendation, not part of the spec

I'll give it some thought.
Could you please open another issue based on this?


@joaomdmoura I'm just throwing my 2 cents in here, but IMO the entire point of JSON API is to avoid bike shedding.

If the JSON API recommends dashes and the adapter is a JSON API adapter, then just do dashes. I may not prefer it, you may not prefer it, "Rails" may not prefer it, but in the grand scheme of things whether we use dashes vs underscores vs camelCase vs whatever the new hotness is, doesn't really matter.

What does matter is that everyone joins together on that consensus so that we can move on to more important things.

rails-api member

@jfelchner totally agree. As I said in my last comment, indeed this is the recommendation. We should follow it. We can keep it up on your PR.


First of all, thanks for this! :)

I've been looking around to find out what the "default value" for key_format actually is; our serializers are configured globally to use :lower_camel as the key format, but there are some places where we have to deal with backward compatibility and as such we should use the default snake case.

For now I've settled for something recognisable, i.e. format_keys :underscored, but I was just curious to hear from a more authoritative source ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment