[JSON-API] Nested polymorphic representation

[caseymct]

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.

[lasseebert]

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?

[lasseebert]

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

[apotonick]

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.

[lasseebert]

@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 ;)

[myabc]

This issue was moved to trailblazer/roar-jsonapi#10