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

Don't pluralize the CollectionSerializer#root for #json_key #1418

Merged
merged 1 commit into from
Jan 25, 2016

Conversation

Empact
Copy link
Contributor

@Empact Empact commented Jan 7, 2016

One of three constituents is used to provide the CollectionSerializer's #json_key:

  1. the :root option - controlled by the caller
  2. the #name of the first resource serializer - the root or
    underscored model name
  3. the underscored #name of the resources object - generally
    equivalent to the underscored model name of Remove Rails Dependency #2

Of the three, only the latter 2 are out of the callers control, and
only the latter two are expected to be singular by default. Not
pluralizing the root gives the caller additional flexibility in
defining the desired root, whether conventionally plural,
unconventionally plural (e.g. objects_received:) or singular.

@Empact Empact force-pushed the collection-pluralize branch from 61d1d9f to 047f11f Compare January 7, 2016 19:48
@@ -171,7 +171,7 @@ def test_render_array_using_custom_root
with_adapter :json do
get :render_array_using_custom_root
end
expected = { custom_roots: [{ name: 'Name 1', description: 'Description 1' }] }
expected = { custom_root: [{ name: 'Name 1', description: 'Description 1' }] }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically this is a breaking change. I think this is ok since we still haven't released 0.10 but a note in the changelog would be good

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see this breaking a lot of apps.. I'm wondering how we can communicate that? @rails-api/ams

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's in the changelog under breaking changes so I think it's good now.

@bf4
Copy link
Member

bf4 commented Jan 10, 2016

You wrote:

expected to be singular

Would you mind pointing me to where the JSON adapter collection root is expected to be singular?

Indeed for JSON API this is configurable, but not for the JSON adapter.

@Empact
Copy link
Contributor Author

Empact commented Jan 11, 2016

@bf4 I wrote

Of the three, only the latter 2 are out of the callers control, and
only the latter two are expected to be singular by default.

the latter 2 are expected to be singular (unless overriden), because they are drawn from the classes that are not collection-oriented - either the json_key of a non-collection serializer, or the name of the collection object - which is singular assuming this is geared toward rails where:

>> Profile.limit(10).name
=> "Profile"

I'm not sure what you mean by JSON adapter collection root.

@Empact Empact force-pushed the collection-pluralize branch from 11f3d68 to 1989498 Compare January 12, 2016 01:14
singular_key = serializers.first.try(:json_key) ||
object.try(:name).try(:underscore)
singular_key.try(:pluralize)
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what a mess this code is. maybe have this be something like root || derived_root so it's a little easier to see what's going on? I initially missed that the fundamental change was no longer modifying root when present

@bf4
Copy link
Member

bf4 commented Jan 12, 2016

Looks good. Just some small comments

One of three constituents is used to provide the
CollectionSerializer's #json_key:

1) the :root option - controlled by the caller
2) the #name of the first resource serializer - the root or
   underscored model name
3) the underscored #name of the resources object - generally
   equivalent to the underscored model name of rails-api#2

Of the three, only the latter 2 are out of the callers control, and
only the latter two are expected to be singular by default. Not
pluralizing the root gives the caller additional flexibility in
defining the desired root, whether conventionally plural,
unconventionally plural (e.g. objects_received:) or singular.
@Empact Empact force-pushed the collection-pluralize branch from 1989498 to 251e33a Compare January 12, 2016 17:33
@Empact
Copy link
Contributor Author

Empact commented Jan 12, 2016

@bf4 Should be good to go

@natematykiewicz
Copy link

@bf4, I know you said this could break a lot of apps. Do you think it's worth creating a setting for it, or just let it be part of upgrading to 0.10?

@bf4
Copy link
Member

bf4 commented Jan 19, 2016

@natematykiewicz good question. @joaomdmoura how about after we merge this we immediately cut rc4?

@Empact
Copy link
Contributor Author

Empact commented Jan 19, 2016

Incidentally the other changes I've been putting together so far have been additive only. I think an RC to socialize this would be good, and I'm open to alternatives.

@beauby
Copy link
Contributor

beauby commented Jan 20, 2016

LGTM. For a future PR, it might be worth extracting most of the root / json_key logic into the Attributes adapter, as it is the only one actually making use of it (JsonApi uses a custom type option, which could very well be just an alias to root actually).

@Empact
Copy link
Contributor Author

Empact commented Jan 20, 2016

Interesting - incidentally I also have a branch adding the :except option to Attributes only.

https://github.com/brigade/active_model_serializers/tree/attributes-except

kurko added a commit that referenced this pull request Jan 25, 2016
Don't pluralize the CollectionSerializer#root for #json_key
@kurko kurko merged commit ef58efd into rails-api:master Jan 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants