[JSON-API] Nested polymorphic representation

[myabc]

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]

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