Traits view

[austinkline]

Add Traits view to return the traits of an NFT.

You can find discussion about this view in #74

Some snippets from the original ticket:

Traits - A way to represent the underlying metadata or an item. This would replace views like TopShot's TopShotMomentMetadataView so that we can standardize what types are being vended from all these different collections set to come out once permission-less deployment is enabled at our June 15th spork.

An Attribute really is a wrapper around a single key-value pair and tells you:

• What is the value?
• What is the name of the value?
• How should I show this value? (Optional)

The last piece (how to show a value) is the key part here for why it is different than another {String: AnyStruct} dictionary. Some pieces of metadata are more useful when contextualized with an additional disclaimer.

Take, for example, an attribute that represents the time in which the item was minted. Most likely, that attribute is going to be the block timestamp accessible to us in cadence and will be a number. So, instead of showing a number as the dateMinted attribute, I can set its display type to Date and platforms know to take that number and attempt to parse it differently. So now we've gone from returning

{
  "dateMinted": 1653409561
}

to

[
  {
    "traitType": "dateMinted",
    "value": 1653409561,
    "displayType": "Date"
  }
]

[joshuahannan]

Looks good so far! Should we also include Rarity in the ExampleNFT contract resolver, or do we think that it will only be used for traits?

Also, how do we feel about having a Traits view that just includes an array of Trait like we do for the other views?

[austinkline]

Looks good so far! Should we also include Rarity in the ExampleNFT contract resolver, or do we think that it will only be used for traits?

Rarity I debated about before submitting this. I wanted to showcase the helper function to generate traits that don't need special handling. I could add a third rarity trait as well if we want and it would just be separate from the other two?

Also, how do we feel about having a Traits view that just includes an array of Trait like we do for the other views?

I was thinking about this, I generally don't like having Object.object kind of syntax, like a Traits struct having a traits field in it. At the same time, all our other views are non-array types. Sounds like there are other places where this is up in the air as @bjartek has asked about in #95

[bjartek]

I think adding Traits makes sense since we already have the pattern in all the other views.

[austinkline]

I think adding Traits makes sense since we already have the pattern in all the other views.

I can live with that, sure. Not my ideal but I agree it's better we adhere to established precedent, especially if it's just nitpicks like this. Will update tonight

[psiemens]

Looks good overall! Left a couple suggestions and then one question about the rarity score field.

[psiemens]

LGTM 👍

[psiemens]

@aishairzay @joshuahannan This PR looks good to me. Any final feedback?

Thanks for pushing this through @austinkline!

[aishairzay]

LGTM !

[joshuahannan]

I still think it would be good to have a stringDictToTraits(_ dict: {String: String}): Traits utility function. Does anyone object to adding that? Also have you run all the tests with make test to make sure everything passes? I still haven't figured out how to get CI to run for PRs from forks

[austinkline]

I still think it would be good to have a stringDictToTraits(_ dict: {String: String}): Traits utility function. Does anyone object to adding that? Also have you run all the tests with make test to make sure everything passes? I still haven't figured out how to get CI to run for PRs from forks

So just to make sure I understand the value-add, shouldn't I be able to use a {String: String} as {String: AnyStruct} for a method input?

All tests pass using make ci

[joshuahannan]

You're right, I guess it does work. I didn't know if the type system would be ok with that. I'm fine with it then