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

Refactor JSONAPI adapter #1103

Merged
merged 15 commits into from
Sep 6, 2015
Merged

Conversation

beauby
Copy link
Contributor

@beauby beauby commented Aug 31, 2015

  • Move id and json_api_type methods from Serializer to JsonApi
  • Globally refactor JsonApi adapter

object.class.model_name.singular
end
end

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These two methods clearly did not belong there, as they are JSONAPI specific.

Copy link
Member

Choose a reason for hiding this comment

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

👍 I'm happy we finally did it!

@beauby beauby force-pushed the fix-jsonapi-ri branch 2 times, most recently from 6fdd377 to 549e52c Compare September 1, 2015 08:03
if serializer.respond_to?(:each)
serializer.map { |s| resource_identifier(s) }
else
if options[:virtual_value]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

After giving it a thought, why would anyone ever use a virtual value for a relationship with json_api? The only value this can take is nil or a Resource Identifier/array of Resource Identifiers, which means the virtual attribute has to be either of those, which means the use case is something like:

PostSerializer < ActiveModel::Serializer
  attributes :id, :name
  belongs_to :author

  def author
    { type: 'authors', id: '3' }
  end
end

which in turn implies that one can't really include the corresponding resource.

Hence, I vote for removing the virtual values for relationships with json_api adapter.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe we could do something similar to JsonAdapter, that if found a instance of an model object it will query that object and use it as the relationship. I know that it might be an edge case, but would be nice to cover, taking into account the level o abstraction we are working with when trying to cover everyone using AMS 😁

@beauby
Copy link
Contributor Author

beauby commented Sep 6, 2015

Rebased.

@@ -9,7 +9,13 @@ def initialize(serializer, options = {})
super
@hash = { data: [] }

if fields = options.delete(:fields)
@options[:include] ||= []
if @options[:include].is_a?(String)
Copy link
Member

Choose a reason for hiding this comment

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

Can you explain more about this. It's not related to type and id, and I also don't understood the why of String verification + split

Copy link
Member

Choose a reason for hiding this comment

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

nvm, understood 😁

@joaomdmoura
Copy link
Member

LGTM, I'm merging it

joaomdmoura added a commit that referenced this pull request Sep 6, 2015
Move `id` and `json_api_type` methods from `Serializer` to `JsonApi`.
@joaomdmoura joaomdmoura merged commit 2375420 into rails-api:master Sep 6, 2015
@joaomdmoura
Copy link
Member

Oh, could you please @beauby open a PR with a new 'how to' article explaning how to override id and type?

@beauby beauby changed the title Move id and json_api_type methods from Serializer to JsonApi. Refactor JSONAPI adapter Sep 7, 2015
@beauby
Copy link
Contributor Author

beauby commented Sep 7, 2015

@joaomdmoura With this PR, type cannot be overridden (but a small change as in #1122 allows for that as well). Type can be overridden as one would expect it, by defining an id method on the serializer class. Maybe a little note in the existing doc would make more sense than a whole article.

@joaomdmoura
Copy link
Member

The article size don't bother me and indeed it can even be a note, just want to make it easier to be found 😄 but I'll check it on #1122

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

Successfully merging this pull request may close these issues.

3 participants