Card Relationship Polymorphism

gistfile1.txt

// In this example we control the types of cards that are allowed in the event relationship
// using the "related-cards" relationship that hangs off of the field.

{
  data: {
    type: 'cards'
    id: '@acme/ticket-tools::ticket-card:123',
    ... 
  },
  included: [
    // This field is a belongs-to of the card in the document data,
    {
      type: 'fields'
      id: '@acme/ticket-tools::ticket-card::attendee',
      attributes: {
        'is-metadata': true,
        'needed-when-embedded': true 
      },
      relationships: {
        'field-type': {
          data: { type: 'cards', id: '@cardstack/core-types::belongs-to-field-card' }
        },
        // The idea is that we accept any card whose adopt graph can be traced back (via any path) to the card specified below. In this
        // example cardstack is providing a core user card that has metadata for a user. Cards
        // can adopt from @cardstack/user::user-card to provide a user card
        'related-cards': {
          // Note that this is intentionally a belongs-to relationship. If there are mulitple interfaces
          // that can fit in this relationship, they should be encapsulated within a single card.
          // Experience with the current hub API's `related-types` has shown us that this is better
          // expressed using a belongs-to instead of a has-many.
          data: { type: 'cards', id: '@cardstack/user::user-card::v1.0.0' } 
        }
      }
    },
  ]
}