-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create FungibleTokenMetadataViews contract #89
Conversation
There are at least two thing I'd love to have some input, the contract name and how to deal with the |
|
||
/// Function that allows creation of an empty FT vault that is intended | ||
/// to store the funds. | ||
pub let createEmptyVault: ((): @FungibleToken.Vault) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reasoning for this createEmptyVault
function to be inside the FTVaultData
struct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
People can get metadata views from an object without importing or knowing what contract the object comes from, so this view allows code that has the object or a reference to it, but not the imported contract, to be able to create a new vault and also know what the storage and public paths are for it without having to find out that information elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far! I think the name is good and just copying MetadataViews
into the utility contracts directory here is probably fine until we figure out a better way to manage it.
Now we just need to add some tests and we can start sharing this PR around a bit more for reviews
bannerImage: MetadataViews.Media, | ||
socials: {String: MetadataViews.ExternalURL} | ||
) { | ||
self.name = name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about the token symbol?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanna discuss over the FLIP on the forum about the fields of this FTDisplay
, the symbol is a really good catch, and I also would like to discuss which images we really do need for the FTs, I'm not sure at all that we need a square and a banner Image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you please mention the flip here
I love where this is heading! From Blocto's perspective, it would be useful to include 2 different kinds of logos in
|
Hi @boczeratul! It's such an honour that you like this proposal. What do you think if we turn Just for context pub struct Medias {
/// An arbitrary-sized list for any number of Media items
pub let items: [Media]
init(_ items: [Media]) {
self.items = items
}
} |
Awesome 👍 |
contracts/FungibleToken.cdc
Outdated
/// @return An array of Types defining the implemented views. This value will be used by | ||
/// developers to know which parameter to pass to the resolveView() method. | ||
/// | ||
pub fun getViews(): [Type]{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshuahannan I've done the default implementations of the Resolver functions on this branch since it seemed to me that it belonged more to the features than to the example, does it look good?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that looks good. The version of Cadence that you're using to test it supports default implementations and is working, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic looks good! My comments are almost entirely stylistic.
@@ -0,0 +1,740 @@ | |||
import FungibleToken from "./../FungibleToken.cdc" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another nitpick, but I think the flow-nft
repo stores utility contracts in contracts/utility
. Feels a bit redundant to mention "contracts" again in contracts/utilityContracts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have a pretty good point there, should we change the folder's name here and on the flow-nft
repo @joshuahannan ???
Thanks a lot for your comments @psiemens! I love descriptive names on variables so I love the "maybeView" names, it makes the code way more readable!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM!
@satyamakgec
According to the PR Template I should move the version to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, a small comment about the required restrictions of the balancer cap.
) { | ||
pre { | ||
receiverLinkedType.isSubtype(of: Type<&{FungibleToken.Receiver}>()): "Receiver public type must include FungibleToken.Receiver." | ||
metadataLinkedType.isSubtype(of: Type<&{FungibleToken.Balance, MetadataViews.Resolver}>()): "Metadata public type must include FungibleToken.Balance and MetadataViews.Resolver interfaces." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this also ensure that it is a subtype of receiver? personally I never understood why FT capabilities do not link both receiver and balance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good question. I guess that if we are making sure that a {FungibleToken.Receiver}
is provided on the receiverLinkedType
we don't need to check for it on the metadataLinkedType
.
Also you make me thing if we really want to be checking that the providerLinkedType
is also a {MetadataViews.Resolver}
Quick thought, we might want to support the TokenForwarder pattern that both A couple potential solutions...
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Just needs Go assets updated for CI to build properly
@bshahid331 can you elaborate on what you would want with a code sample? IMO these use cases are not that common and will be phased out eventually, so I don't see much reason to build them into the standard. It might make more sense for those forwarder contracts to upgrade their contracts and relink their paths so that their forwarders expose the metadata though, if that is what you want |
@joshuahannan I agree, not a common use case. It can be a custom MetadataView like the TopShot ones that dapper wallet fungible tokens can support. If you look at dapper wallet transactions there is the main dapper vault path that stores all the DUC for example. Then each account has a receiver path that is essentially what you deposit DUC too. Custom use case but still DUC and FUT are the main FT's being used outside of Flow that's why I wanted to bring it up. |
I have one main question. Currently in the FungibleToken contract, we have the Vault resource implementing the Therefore, if we don't want to introduce a breaking change, then the only other way to include this before then would be to put the metadata views methods into one of the existing interfaces, either Does anyone have any thoughts? I'll probably just add it to |
247fb07
to
ee3dd49
Compare
Closes: #82
Description
Creates the contract for the Fungible Token's Metadata Views.
For contributor use:
master
branchFiles changed
in the Github PR explorer