# ContentObject refac proposal

The goals of this proposal are:
- Make ContentObject type more semantic, thus making our overall GraphQl interface clearer.
- Remove complexity overhead (both FE and BE) of having to deal with lists when we actually can only have 1 object per note.

## The polimorfism problem

Right now we handle the polimorfism of the ContentObject type by conditionally rendering components based on the `type` field and trusting that the correct we have the right data in the `data` field. Take the `contentObject` query for instance.

query {
  contentObject(by: {id: "some_id"}) {
    id
    title
    identifier
    type
    data
    metadata { # ????
      contentObjectId
      publicNotesCount
      data
    }
  }
}

Using the `type` field to understand wich concrete object is being handled is fine, the main problem lies on the `data` field that it's a wild card, relying solely on the knowlodge of the developer of know that "object with type X has data with the fields Y, Z and T".

A much clearer and "graphqlish" aproach would be to use a [GraphQl inteface](https://graphql.org/learn/schema/#interfaces) to define the comon fields and extend it to the concrete objects with the explict exclusive fields, something like:

query {
  contentObject(by: {id: "some_id"}) {
    id
    title
    identifier
    type
    thumbnail
    ... on BookObject {
        chapter
        authors
        # ... other useful fields
    }
    ... on MVQuestObject {
        day
        # ... other useful fields
    }
    ... on MVEvebtObject {
        startDate
        netoworkIds
        # ... other useful fields
    }
    ... on on LinkObject {
        keywords,
        description
        # ... other useful fields
    }
  }
}

This way we can keep the component rendering based on the `type` field but the values of `data` are always explict when self documenting our API making easier for other teams and ourselves to use.

## Removing the list complexity.
As we're only dealing with one attached object per note and we don't see that changing in the forseable future, there's no reason to keep this "working with lists" overhead, this would greatly simplify both frontend and back end code. So given now we have something like:

query{
    note(id: "some_id"){
        title
        description
        tags
        contentObjectMetadata {
          contentObjectId
          data
        }
        books {
          identifier
          title
          data
          type
        }
        links {
          identifier
          title
          data
          type
        }
        quests {
          identifier
          title
          data
          type
        }
        events {
          identifier
          title
          data
          type
        }
        channels {
          identifier
          title
          data
          type
        }
     }
}

We can remove all the repeated exclusive fields that now serve the only porpuse of separating the content objects into lists of the same type to a single field using the an interface:

query{
    note(id: "some_id"){
        title
        description
        tags
        contentObjectMetadata { // ????
          contentObjectId
          data
        }
        contentObject {
          identifier
          title
          type
          ... on BookObject {
            chapter
            authors
            # ... other useful fields
          }
          ... on MVQuestObject {
            day
            # ... other useful fields
          }
          ... on MVEvebtObject {
            startDate
            netoworkIds
            # ... other useful fields
          }
          ... on on LinkObject {
            keywords,
            description
            # ... other useful fields
          }
        }
     }
}