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

[JSON-API] Nested polymorphic representation #10

Open
myabc opened this issue Dec 10, 2016 · 5 comments
Open

[JSON-API] Nested polymorphic representation #10

myabc opened this issue Dec 10, 2016 · 5 comments
Assignees

Comments

@myabc
Copy link
Collaborator

myabc commented Dec 10, 2016

From @caseymct on January 22, 2016 2:22

Trying to transition from a standard representer format to json-api. I have a model, Notification, that has a polymorphic target - it can be one of many different types. How would I write this

class NotificationRepresenter < ApplicationRepresenter
  wrap_with :notifications

  timestamp :read_at
  timestamp :sent_at, writeable: false
  property :notification_type, writeable: false
  property :message_variables, writeable: false
  property :representable_target, as: :target, decorator: proc {
    representable_target.representer
  }
end

as a JSON-API compliant response? or can I? Somehow I need to set a has_one with a class that is determined by representable_target, then have the block return that target's data.

Copied from original issue: trailblazer/roar#183

@myabc
Copy link
Collaborator Author

myabc commented Dec 10, 2016

From @lasseebert on April 15, 2016 8:40

I have run into the same issue. I have a polymorphic relation: An AccountUser has one Account which can be one of several types of accounts.

I want to render the same properties for each account, but I need the type to be different.

Something like this:

class AccountUserView < Roar::Decorator
  include Roar::JSON::JSONAPI

  type "account-users"
  property :id
  property :another_property

  has_one :account do
    type { |account| account.type } # <-- this must be variable depending on the type of account
    property :id
    property :some_other_property
  end
end

Can this be done somehow?

@myabc
Copy link
Collaborator Author

myabc commented Dec 10, 2016

From @lasseebert on April 15, 2016 9:23

I have messed around in the roar code and solved this so that type now accepts both a string and a block (mutually exclusive) like my above example.

def type(name=nil, &block)

@apotonick, if you think this is a good idea, I will make some tests and a proper pull request ;)

@myabc
Copy link
Collaborator Author

myabc commented Dec 10, 2016

From @apotonick on April 16, 2016 2:29

The example @caseymct gives is more complicated, @lasseebert! You only need the type dynamic, in the other issue, the entire representer must be interchangable.

I believe it takes a bit more work to cover both of the cases.

@myabc
Copy link
Collaborator Author

myabc commented Dec 10, 2016

From @lasseebert on April 17, 2016 20:45

@apotonick, yes I see now that my issue is not related at all to the original issue posted here, since dynamically deciding the type is not only related to has_one, but could also be useful-ish in the root of a representer.

E.g. in my above example code, I could have an AccountRepresentable that has different jsonapi types, but similar data structure.

The use case for this is pretty thin, so I'll take down my suggestion again ;)

@Titinux
Copy link

Titinux commented Sep 18, 2017

Any news on this topic ? Polymorphism is mandatory in any non basic api. (and I don't say that because I'm working on a huge/urgent project that needs this feature 😅)

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

No branches or pull requests

3 participants