[JSON-API] Nested polymorphic representation about roar-jsonapi

[myabc]

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]

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]

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]

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]

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