Feature/of 328 replace missionaction with one universal entity in the

[george-openformat]

Overview

• Adds new Reward entity that aims to replace both Mission and Action
• Depreciates mission and action entities (still supported, but will remove once we are sure no one is using them)
• Refactors reward facet handlers for easier removal of deprecated functionality in the future

Cleanup

• Removes collectedBadges entity from schema as it is unused
• Removes TODO's in schema

Reasoning

The name Reward

The name Reward has been chosen as it fits the current use case without over abstracting. Event was considered but it is similar to events in solidity and felt it was quite confusing from a dev perspective. Events also felt too abstract for right now and I didn't want take that name and have to settle for something worse later. I'm more than open to other suggestions on this.

Resulting schema

type Reward @entity (immutable: true) {
  id: ID!
  app: App!
  rewardId: String!
  rewardType: String!
  metadataURI: String!
  user: User!
  token: FungibleToken
  tokenAmount: BigInt!
  badge: Badge
  badges: [BadgeToken!]
  badgeCount: Int!
  transactionHash: String!
  createdAt: BigInt!
  createdAtBlock: BigInt!
}

The aim is to improve developer experience by having a less opinionated data structure. By changing the approach in two distinct ways, have the type as a field and don't bundle tokens, we are able to achieve a flat data structure that should be much easier to query against. Moving forward it will be much easier to aggregate also.

The field rewardType

rewardType will be MISSION for missions and ACTION for actions. This should mean we can easily move to using the Reward entity in the api by just changing the queries and not have to change the reward endpoints immediately. We can open it up to any rewardType so that devs can decide how they organise their rewards. For example discord:mission, telegram:mission will let us give more insight into where the rewards were triggered while keeping rewardId to the "for what"

No bundling happens at a subgraph level

An important difference to note is Missions currently bundles tokens and badges rewarded in the same transaction so that badges and tokens could be linked to one mission. Rewards are less opinionated and follow the contract logic on the reward facet exactly.

Pros:

• Simpler schema, and handling logic
• Multicall can now be used to issue lots of different rewards at once
• Aggregations is easier to implement

Cons:

• Bundling would need to happen on the client, via their own logic

To add bundling back in I propose we add it at the contract level and then create a parent entity that groups Reward entities. Or have an explicit bundling logic that does not hinder the functionality of multicall

Staging

I have deployed v0.1.1-alpha to staging to help with review
Playground ->

Example query

{
  # Mission replacement query
  missions: rewards(where: {rewardType: "MISSION"}) {
    rewardId
    rewardType
    metadataURI
    token {
      id
    }
    tokenAmount
    badge{
      id
    }
    badges {
      tokenId
    }
    badgeCount
  }

  # Action replacement query
  actions: rewards(where: {rewardType: "ACTION"}) {
    rewardId
    rewardType
    metadataURI
    token {
      id
    }
    tokenAmount
    badge{
      id
    }
    badges {
      tokenId
    }
    badgeCount
  }
}

[nup9151f]

Nice! 👍