Allow Key Format to Be Overridden and Have Sensible Defaults #1029

jfelchner · 2015-07-31T09:56:31Z

Overriding the Key Format

You can specify that serializers use a different style for the format of the
keys that are sent over. This can be done at the config, class or instance
level.

# Global
ActiveModel::Serializer.config.key_format = :lower_camel

# Per Serializer
class BlogLowerCamelSerializer < ActiveModel::Serializer
  key_format :lower_camel
end

# Per Instance
BlogSerializer.new(object, key_format: :lower_camel)

Currently Supported Key Formats

:unaltered
:lower_camel
:underscore
:dasherize

The default key format will be set depending on the adapter that you specify.
For example, the JSON adapter defaults to lower_camel whereas the JSON API
adapter defaults to dasherize. Any other adapter will default to unaltered.

References: #534, emberjs/data#3455
Closes: #974

Merry Christmas in July everyone. 😀 🎄 🎅

jfelchner · 2015-08-04T03:33:20Z

I looked at the build and everything passed. No idea why it marked it as a failure.

joaomdmoura · 2015-08-08T18:25:20Z

README.md

@@ -170,6 +170,35 @@ class PostSerializer < ActiveModel::Serializer
 end
 ```

+### Overriding the Key Format


👍
It would be awesome if along with this PR you could add some Docs to our new documentation we have being working on before release.
Maybe event add some article about integrating it with ember.js using our How to section.

joaomdmoura · 2015-08-09T19:34:19Z

👍 to the PR itself, I made some comments after reviewing it and we also need to check the tests.
Would be great if we could also squash some commits to keep the ones that makes more sense.
Awesome work @jfelchner, get it up! looking forward to have it on 0.10

jfelchner · 2015-08-09T22:27:39Z

@joaomdmoura I'll get on it and comment back here on Monday or Tuesday. Thanks!

mcmire · 2015-08-10T21:46:20Z

Just wanted to drop by and 👍 this, this looks like a nice addition.

jfelchner · 2015-08-12T07:12:30Z

@joaomdmoura ok, I hit a bit of a snag. I found a bug. :-/

The problem is that we don't want to convert keys for hashes that are inside the values for attributes. Currently it just goes recursively as deep as it needs to to make sure that everything is converted.

For example if we have this:

            @second_post = Post.new(
                            id:                   2,
                            title:                'New Post',
                            body:                 'Body',
                            multi_word_attribute: {
                              multiple_words: 'here are some words'
                            })

we don't want multiple_words to become multiple-words. The implementation I have feels really nice, but it obviously won't work.

Maybe an abstraction is missing or a refactoring is required to make this the "easy" change? I don't have enough familiarity with the codebase so I thought you or someone else might be able to provide some insight.

I think that the end goal is that the following should be converted, but nothing else:

attribute names
association names
types

Those should be converted wherever they are in the hash. Anything else:

top level schema keys like data, etc
values of attributes

should be left alone.

And obviously this is going to vary from adapter to adapter (eg json-api has a relationships hash which contains types, whereas the json adapter does not).

If you can point me in the right direction for implementation, I'll take a crack at it, but I fear I'm going to have to start from square one for the most part to get this right. Which is fine. I'd rather do it right.

joaomdmoura · 2015-08-13T01:24:08Z

Get it @jfelchner, indeed the behavior you described would be most accurate.
We could accomplish it by calling format_key on multiple places: root, attributes (method), associations (method).
I'm not sure how it would like but it seems okay for me in order to keep it simple.
If you want to, we can try to pair on it.
Let me know your thoughts about it 😄

bf4 · 2015-08-13T19:37:31Z

lib/active_model/serializer/array_serializer.rb

      delegate :each, to: :@objects

-      attr_reader :root, :meta, :meta_key
+      attr_reader :root, :meta, :meta_key, :options


It doesn't appear the you're using the options reader in any public contexts. Perhaps we can make it private? (It's just so the KeyFormat mixin can do options[:key_format], right?)

joaomdmoura · 2015-08-17T04:15:22Z

Hey @jfelchner, would be awesome if you could read through #1052.
It's deeply related to what you are working on.

I merged it for now but I would like to handle it on this PR following the same approach as well.

Let me know if there is anything I can do in order to make it easier for you 😄

jfelchner · 2015-08-17T04:19:45Z

@joaomdmoura perfect! I'll take a look. Just been busy the last few days. 😊

jfelchner · 2015-08-17T04:21:59Z

BTW @joaomdmoura I'm absolutely open to pairing on this. 👍🏻

joaomdmoura · 2015-08-17T05:12:15Z

Awesome I did just a few comments, because I know the implementation might change after some changes you will do.

I'm absolutely open to pairing on this.

Cool! Find on Twitter as @joaomdmoura, I will send you my email and we can try to schedule something using screenhero or whatever. But don't wait for me 😁

timurvafin · 2015-08-17T17:14:46Z

lib/active_model/serializer/adapter.rb

+      end
+
+      def format_key(formattable_key)
+        case key_format


Assume we have namespaced object Admin::User then key should be user instead of admin/user. What do you think about adding something like formattable_key.to_s.demodulize?

@timurvafin Do you have a ref for Admin::User -> user? I'm not sure what I would do in such a case.

ref: json-api/json-api#850

jfelchner · 2015-08-17T17:16:15Z

@timurvafin underscore does that by default.

jfelchner · 2015-08-17T17:18:40Z

@timurvafin oh I see what you're saying, you want the opposite. No I don't think that would be a good idea. They are two different classes and therefore two different types. If someone wants to do that they can override manually by overriding json_type on the serializer. Also, this PR doesn't affect values, just the keys.

timurvafin · 2015-08-17T17:20:56Z

@jfelchner probably AMS by default should generate something more json-like for Admin::Post then admin/post. Maybe something like admin-post or admin_post?

jfelchner · 2015-08-17T17:25:38Z

@timurvafin we're using AMS with an app with multiple Rails engines and are using / between our modules and - between words. Unfortunately JSON API isn't clear on what to use and IMO there definitely needs to be a way to differentiate Admin::User from AdminUser so / seemed as good a choice as any.

bf4 · 2015-08-18T19:18:55Z

@jfelchner @timurvafin

Unfortunately JSON API isn't clear on what to use and IMO there definitely needs to be a way to differentiate Admin::User from AdminUser so / seemed as good a choice as any.

might be worth creating an issue in https://github.com/json-api/json-api/ and linking here

jfelchner · 2015-08-18T19:21:14Z

@bf4 👍

The JSON API adapter follows the JSON API spec and therefore should follow JSON API recommendations for naming * http://jsonapi.org/format/#document-member-names * http://jsonapi.org/recommendations/#naming

Just for completeness

beauby · 2015-09-18T01:09:59Z

README.md

+
+For example, the JSON adapter defaults to `lower_camel` whereas the JSON API
+adapter defaults to `dasherize`. Any other adapter will default to `unaltered`.
+


I think the JSON API adapter should default to lower_camel as well to avoid huge confusion on upgrade.

@beauby I am very much in the other camp on that. The JSON API standard recommends dasherized keys and the couple JSON API JS libraries I've seen default to expecting incoming requests to be formatted with dasherized keys.

In the vein of making this Just Work with JSON API, I think it should absolutely be dasherized. Otherwise almost everyone who uses it will need to add the global config option to their projects.

I'll bow to the majority opinion, but I just wanted to voice my concern.

You're right, if JSON API recommends dashes, we should do dashes by default.

Yes, see #1029 (comment) and json-api/json-api#850

This will allow users to override the key format from the controller. Example: ```ruby class MyController < ActionController::Base def index render json: resource, key_format: :underscore end end ```

bf4 · 2015-09-18T04:16:46Z

lib/active_model/serializer/adapter.rb

@@ -11,6 +13,7 @@ class Adapter
      autoload :Null
      autoload :FlattenJson
      autoload :CachedSerializer
+      include Configuration


So, in https://github.com/rails-api/active_model_serializers/pull/1050/files#diff-ae1e38e96a8bf28ae37918a65c448c73R11 I just use e.g. ActiveModel::Serializer.config.jsonapi_toplevel_meta = {}

the require could also be a problem since it's incompatible with rails autoload

We want to be able to allow the user to override the adapter defaults on a project-wide basis.

Rubocop fixes are self-explanatory. The changes to the tests mainly involve reformatting the hash to use hashrockets. These are required on Ruby 1.8 when there are keys that contain characters which cannot be symbolized. Example: ```ruby { foo: 'bar', 'baz-qux': 'foobar', } { :foo => 'bar', :'baz-qux' => 'foobar', } ```

Isolated test methods are going to be long and that's ok. Pushing for tests to be DRY makes individual tests less readable.

bf4 · 2015-10-02T04:01:48Z

Related: #1213

krzkrzkrz · 2015-10-19T16:15:50Z

Any updates on this? Am looking forward to dasherized format as well

tylerwillingham · 2015-11-23T03:27:03Z

I'm also interested in seeing this make it through. Is there anything I can do to contribute?

ref: - rails-api#827 - rails-api#832 - rails-api#872 - rails-api#1045 - rails-api#912 - rails-api#911 - rails-api#904 - rails-api#810 - rails-api#693 - rails-api#849 - rails-api#1029 - rails-api#1300 - rails-api#1372

andrewhavens · 2016-01-06T19:03:49Z

I came across this PR while looking for a way to specify model_name in my serializer. I would like to be able to pass a hash instead of a full model instance to a serializer (to get better performance). Is there already a way to do this in master? Does this PR address this issue?

bf4 · 2016-01-06T21:26:45Z

No, this would be a feature request to pass a naked attributes hash directly into the adapter, i think

B mobile phone

On Jan 6, 2016, at 1:03 PM, Andrew Havens [email protected] wrote:

I came across this PR while looking for a way to specify model_name in my serializer. I would like to be able to pass a hash instead of a full model instance to a serializer (to get better performance). Is there already a way to do this in master? Does this PR address this issue?

—
Reply to this email directly or view it on GitHub.

alessiodallapiazza · 2016-03-03T13:47:56Z

Any updates on this?
It's very useful

remear · 2016-03-15T19:57:43Z

Resolved by #1574

ijunaid8989 · 2016-07-29T06:57:39Z

What is the final results now? This thing is being added to gem?

NullVoxPopuli · 2016-07-29T11:54:04Z

@ijunaidfarooq see: https://github.com/rails-api/active_model_serializers/blob/master/docs/general/rendering.md#key_transform

joaomdmoura reviewed Aug 8, 2015
View reviewed changes

bf4 reviewed Aug 13, 2015
View reviewed changes

joaomdmoura referenced this pull request Aug 15, 2015

defining json_key(root) as model class name

4187213

joaomdmoura mentioned this pull request Aug 15, 2015

Use underscored json_root when serializing a collection #1052

Merged

timurvafin reviewed Aug 17, 2015
View reviewed changes

ferrisoxide mentioned this pull request Aug 18, 2015

feat(CurrentUser): current user service (closes #39) EventideSystems/tool_for_systemic_change#40

Merged

jfelchner added 2 commits September 17, 2015 19:54

Add default key format for the JSON API adapter

3db1b4f

The JSON API adapter follows the JSON API spec and therefore should follow JSON API recommendations for naming * http://jsonapi.org/format/#document-member-names * http://jsonapi.org/recommendations/#naming

Add 'underscore' key format

d071f10

Just for completeness

beauby reviewed Sep 18, 2015
View reviewed changes

jfelchner added 4 commits September 17, 2015 22:51

Change adapter to allow key_format to be passed in and override default

c2cfa4c

Add 'key_format' to the allowed options passed to SerializableResource

5dc5622

This will allow users to override the key format from the controller. Example: ```ruby class MyController < ActionController::Base def index render json: resource, key_format: :underscore end end ```

Add 'json_api' as an alias to 'dasherize'

4c802c0

Update README with new key format documentation

bc48d90

bf4 reviewed Sep 18, 2015
View reviewed changes

jfelchner added 3 commits September 17, 2015 23:24

Add global 'key_format' config option

d2c16c3

We want to be able to allow the user to override the adapter defaults on a project-wide basis.

Exclude tests from rubocop's Metrics/MethodLength cop

36dfa4c

Isolated test methods are going to be long and that's ok. Pushing for tests to be DRY makes individual tests less readable.

jfelchner mentioned this pull request Sep 18, 2015

FlattenJson adapter no longer inherits Json adapter, renamed to Attributes #1117

Merged

1 task

bf4 mentioned this pull request Sep 30, 2015

Namespace separator fix for type field in jsonapi adapter #1216

Closed

bf4 added the S: Changelog Missing label Oct 2, 2015

bf4 mentioned this pull request Oct 2, 2015

Namespaced serializer lookup for associations #1196

Closed

bf4 mentioned this pull request Jan 29, 2016

Document JSON API implementation defs and progress in class #1482

Merged

bf4 added the C: JSON API label Jan 29, 2016

bf4 mentioned this pull request Mar 10, 2016

Provide key transformation #1574

Merged

remear closed this Mar 15, 2016

rails-api locked and limited conversation to collaborators Jul 29, 2016


		For example, the JSON adapter defaults to `lower_camel` whereas the JSON API
		adapter defaults to `dasherize`. Any other adapter will default to `unaltered`.

Allow Key Format to Be Overridden and Have Sensible Defaults #1029

Allow Key Format to Be Overridden and Have Sensible Defaults #1029

Conversation

jfelchner commented Jul 31, 2015

Overriding the Key Format

Currently Supported Key Formats

jfelchner commented Aug 4, 2015

Choose a reason for hiding this comment

joaomdmoura commented Aug 9, 2015

jfelchner commented Aug 9, 2015

mcmire commented Aug 10, 2015

jfelchner commented Aug 12, 2015

joaomdmoura commented Aug 13, 2015

Choose a reason for hiding this comment

joaomdmoura commented Aug 17, 2015

jfelchner commented Aug 17, 2015

jfelchner commented Aug 17, 2015

joaomdmoura commented Aug 17, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jfelchner commented Aug 17, 2015

jfelchner commented Aug 17, 2015

timurvafin commented Aug 17, 2015

jfelchner commented Aug 17, 2015

bf4 commented Aug 18, 2015

jfelchner commented Aug 18, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bf4 commented Oct 2, 2015

krzkrzkrz commented Oct 19, 2015

tylerwillingham commented Nov 23, 2015

andrewhavens commented Jan 6, 2016

bf4 commented Jan 6, 2016

alessiodallapiazza commented Mar 3, 2016

remear commented Mar 15, 2016

ijunaid8989 commented Jul 29, 2016

NullVoxPopuli commented Jul 29, 2016