Support lowerCamel key format

[kylefritz]

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
end

class BlogLowerCamelSerializer < ActiveModel::Serializer
  format_keys :lower_camel
end

BlogSerializer.new(object, 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.

[bobbywilson0]

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.

[daemonsy]

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

👍

[kylefritz]

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
end

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

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

class ThingSerializer < ActiveModel::Serializer
  has_many :other_things
end

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

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.

[felixflores]

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]

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. :)

[zavan]

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

[joaomdmoura]

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

[zavan]

Thanks @joaomdmoura. Will it be implemented?

[joaomdmoura]

@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?

[kylefritz]

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.

[joaomdmoura]

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 😄

[kylefritz]

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.

[zavan]

Hi guys, I have a few old projects using this format (some angular, some
without frameworks), because it feels better than working with underscores
in Javascript, I wanted to update their AMS version, that's why I asked. I
think this is an important feature for anyone using Javascript without a
standardized format, but no hurry, everything is fine :)

Em seg, 1 de jun de 2015 12:36, Kyle Fritz notifications@github.com
escreveu:

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.

—
Reply to this email directly or view it on GitHub
#534 (comment)
.

[zavan]

Kyle, it would be very useful if the format got inherited by subclasses,
for example, I have a project with 2 APIs, a legacy one with underscores,
and a new one with lowerCamel, so in one of them, I need to specify the
format in every serializer.
I'll wait for your PR, and if necessary, work on it to provide this.

Em seg, 1 de jun de 2015 13:05, Felipe Zavan emailbloggers@gmail.com
escreveu:

Hi guys, I have a few old projects using this format (some angular, some
without frameworks), because it feels better than working with underscores
in Javascript, I wanted to update their AMS version, that's why I asked. I
think this is an important feature for anyone using Javascript without a
standardized format, but no hurry, everything is fine :)

Em seg, 1 de jun de 2015 12:36, Kyle Fritz notifications@github.com
escreveu:

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.

—
Reply to this email directly or view it on GitHub
#534 (comment)
.

[grin]

would be great to have this working in 0.10 👍

[kylefritz]

@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

returns

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

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

[joaomdmoura]

@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.

[kylefritz]

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

[hugopeixoto]

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[super.map do |key, value|
      [key.to_s.dasherize.to_sym, value]
    end]
  end
end

[joaomdmoura]

hey @hugopeixoto,
just checked with json api folks.

dashes are just a recommendation, not part of the spec
reference

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

[jfelchner]

@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.

[joaomdmoura]

@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.

[datibbaw]

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

[om-nishu-trantor]

It is not working for version 0.10.6

[bf4]

@om-nishu-trantor Please open a new issue if you're looking for help or to help others. Commenting on an issue closed 3 years ago in general is considered 'necromancy', and should only be done with care. In this case, I believe the PR refers to a version which is a long distant cousin of yours.