Enhancement: Add Cleanup Functions

[rheaplex]

To address #21 , I propose adding the following function:

...
pub contract NFTStorefront {
...

    pub resource interface StorefrontPublic {
        pub fun getListingIDs(): [UInt64]
        pub fun borrowListing(listingResourceID: UInt64): &Listing{ListingPublic}?
        pub fun cleanup(listingResourceID: UInt64)
        pub fun cleanupMatching(listingId: UInt64, otherIds: [UInt64])
   }

   ...

    pub resource Storefront : StorefrontManager, StorefrontPublic {
    ...
    // This can be called publicly by anyone.
    // It destroys all the provided Listings, including listingId, if they refer to the same Type/NFT.id.
    // It will fail if listingId is included in otherIds.
    // Note that we do not try to borrow the NFTs to check this, as they may already have been moved.
    // We get our security from the fact that their types and IDs were asserted when the entries were created.
    //
    pub fun cleanupMatching(listingId: UInt64, otherIds: [UInt64]) {
        pre {
            self.listings[listingResourceID] != nil: "could not find listing with given id"
        }

        let listing =  <- self.listings.remove(key: listingId)
            ?? panic("listing is not purchased, only admin can remove")
        let details = listing.getDetails()

        assert(!details.purchased, message: "Listing is still open")

        let nftType = details.nftType
        let nftId = details.nftID

        for otherId in otherIds {
            let otherListing =  <- self.listings.remove(key: otherId)
                ?? panic("listing is not purchased, only admin can remove")
            let otherDetails = listing.getDetails()
            let otherType = otherDetails.nftType

            assert(therDetails.nftType == nftType)
            assert(otherDetails.nftID == nftId, message: "listing NFT id does not match target NFT id")

            destroy otherListing
        }

        destroy listing
    }

Note that we could also keep track of related listings within the same storefront, but this has two issues:

1. It cannot remove listings for the same item across different storefronts.
2. Given that the code has been deployed to mainnet, and given the current contract update rules, we cannot add the required member variables to the storefront resource. This means that we would have to lazily create a new resource in storage, and that is not something we wish to do in reference code if we can avoid it.

[bluesign]

Is there anyone currently using StoreFront on production ? or indexing from events etc ?

If no-one is using as a marketplace, maybe it can be better to focus on personal level usage instead of marketplace usage.

For me expecting publicly someone to call contract to clean up someone else's mess and pay transaction fees while doing so is little funny little sad unfortunately.

[bymi15]

@bluesign Following up on the comment you made almost a year ago 😆
I was wondering if this is actually being used by any marketplaces and what is the recommended practice for cleaning up expired listings - are the marketplaces expected to call this on a regular basis and clean up their own mess? Because as you said paying the transaction fee sounds like a limitation.. and my guess is that marketplaces would simply filter out the expired listings from the UI.

Also, I was wondering what happens if someone attempts to purchase an item that has expired but hasn't been 'cleaned up' yet. Would that transaction go through? Or would it return an error and trigger the clean up.