bebner / crypto-dappy Goto Github PK

Is your feature request related to a problem? Please describe.
Users first have to get FUSD first before they can add any Dappy or Pack to their collection. That's a barrier of entry for many new users.

Describe the solution you'd like
It would be great to give out one free pack to any new user, so that one can interact with CryptoDappy right on the first time. Also, in this first transaction, the collection needed to collect Dappies could be automatically checked and initialised (if not existing).

Describe the bug
All mint-related functions expect a paymeValut which is in standard @FungibleToken.Vault inteface.

It should strictly define the Vault type e.g @FUSD.Valut otherwise anyone can deploy a FungibleToken and mint Dappies.

To Reproduce
Steps to reproduce the behaviour:

1. Deploy a FakeUSD contract and mint to self
2. Create Transaction and pass &FakeUSD.Vault resource as payment to mintDappy
3. The current CrpytoDappy contract will still allow the minting

Hi,

for me the creation of a FUSD vault is not working. I compared the code produced using the video tutorial with the one in the repo and it is 1:1 identical.

I'm working on MacOS 11.5.2, using Chrome and Safari. The Webbrowser developer console does not show any error. However it is still stuck with the saying "Enable FUSD". It initiates the transaction (Approval via blocto).

Besides that the swap of Flow to FUSD is not working due to unavailable FUSD resource. Is there any cycle when there will be new FUSD available for swap on testnet ?

i.e.

self.AdminStoragePath = /storage/DappyAdmin
self.account.save<@Admin>(<- create Admin(), to: self.AdminStoragePath)`

Describe the bug
I use windows WSL2 (ubuntu 20.04)
When I try to complete my mission#1, my browser show connect refuesd.
Not sure if WSL2 is compatible for that.

To Reproduce
Steps to reproduce the behavior:

1. run ''npm start"
2. go to "localhost:3000"
3. Click on 'sign in to start '
4. See error "localhost:3000 connect refused"

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: windows 10 run WSL2(ubuntu 20.04)
• Browser: chrome &Edge

Is your feature request related to a problem? Please describe.
The cryptodappy DappyContract smart contract does not implement the NonFungibleToken contract interface and the Dappy resource does not implement the INFT interface.

It would be good for it to be consistent with how NFTs should be created practically.

Describe the solution you'd like
Create a new optional, advanced mission that walks user through the step of implementing the interfaces.

Another option is to give users hints and notes that the DappyContract smart contract requires implementation of the aforementioned interfaces in practical applications.

Either way, there should be a DappyNFTContract.cdc file in the final mission's code that shows how the smart contract with the interfaces implemented should look so users who are keen to learn more have a reference point.

Additional context
Since cryptodappy was created for learning purposes, it is understandable why it doesn't comply with the interfaces but it would still be a good idea to let users understand the implementation of the interfaces.

Describe the bug
The purchase of a Pack with insufficient FUSD funds silently fails.

To Reproduce
Steps to reproduce the behavior:

1. Enable FUSD Wallet (if not enabled yet) by clicking on "Enable FUSD" in the upper left corner of the page.
2. Set up a collection (if not set up yet) by navigating to "Collection" and then click on "Enable Collection"
3. Navigate to Packs page and click on any pack
4. Click on the FUSD price (needs to be higher than your FUSD balance) to purchase the pack and confirm the transaction
5. See that nothing happens

Expected behavior
The expected behaviour would be an error message or alert that the FUSD balance is not sufficient and therefore the purchase is aborted.

Desktop (please complete the following information):

• MacOS
• Chrome
• Version 92

Describe the bug
The purchase of a Dappy with insufficient FUSD funds silently fails.

To Reproduce
Steps to reproduce the behavior:

1. Enable FUSD Wallet (if not enabled yet) by clicking on "Enable FUSD" in the upper left corner of the page.
2. Set up a collection (if not set up yet) by navigating to "Collection" and then click on "Enable Collection"
3. Navigate to Dappy page and buy a Dappy that costs more than your FUSD balance.
4. See that nothing happens

Expected behavior
The expected behaviour would be an error message or alert that the FUSD balance is not sufficient and therefore the purchase is aborted.

Desktop (please complete the following information):

• MacOS
• Chrome
• Version 92

Describe the bug
Error Type mismatch occured in mission-2. it's LIST_DAPPY_TEMPLATE script.

To Reproduce
Steps to reproduce the behavior:

1. add this scripts to list-dappy-templates.script.js

export const LIST_DAPPY_TEMPLATE = `
    import DappyContract from 0xDappy

    pub fun main(): { UInt32: DappyContract.Template } {
        return DappyContract.listTemplates()
    }
`;

2. execute a command sh run.sh
3. Go to dappies page.
4. error occured

Expected behavior
console

{
	"code": 400,
	"message": "Invalid Flow argument: failed to execute the script on the execution node execution-5f6c73a22445d7d958c6a37c1f3be99c72cacd39894a3e46d6647a9adb007b4d@execution-001.devnet38.nodes.onflow.org:3569=100: rpc error: code = InvalidArgument desc = failed to execute script: failed to execute script at block (39e392a18fe68ade2fc4a1a4461f48472bd0c0a36c1e3bd71ea78f0927b0bb4c): [Error Code: 1101] error caused by: [Error Code: 1101] cadence runtime error: Execution failed:\nerror: mismatched types\n   --\u003e db3d539e48a805b7.DappyContract:225:21\n    |\n225 |     let familyRef = \u0026self.families[familyID] as! \u0026Family\n    |                      ^^^^^^^^^^^^^^^^^^^^^^^ expected `DappyContract.Family`, got `DappyContract.Family?`\n\nerror: mismatched types\n   --\u003e db3d539e48a805b7.DappyContract:240:21\n    |\n240 |     let familyRef = \u0026self.families[familyID] as! \u0026Family\n    |          ...  find type in this scope: `DappyContract`\n --\u003e 89f4de94e0a12e080f0d2facf1e3ff0213e4dc5001a93b5f94b2ec3454194088:4:30\n  |\n4 |     pub fun main(): { UInt32: DappyContract.Template } {\n  |                               ^^^^^^^^^^^^^ not found in this scope\n\nerror: cannot find variable in this scope: `DappyContract`\n --\u003e 89f4de94e0a12e080f0d2facf1e3ff0213e4dc5001a93b5f94b2ec3454194088:5:15\n  |\n5 |         return DappyContract.listTemplates()\n  |                ^^^^^^^^^^^^^ not found in this scope\n"
}

Screenshots

Desktop (please complete the following information):

• OS: Mac OS (M1)
• Browser chrome
• Version 107.0.5304.87

I have implemented the code in misson-3, however the following issue happens when loading the http://localhost:3000/dappies page.
Access to fetch at 'https://access-testnet.onflow.org/v1/scripts?block_height=sealed' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled. http-request.js:102 POST https://access-testnet.onflow.org/v1/scripts?block_height=sealed net::ERR_FAILED 404

Is your feature request related to a problem? Please describe.
I would like to extend the Template struct functionality and wanted to get your advice on the best way to organize the code for it:

1. Would like to restrict minting of Dappies from a template by introducing a retired flag, similar to what the TopShot did.
2. Would like to keep track how many Dappies were minted for each Template.
3. Would like to set a maximum number of Dappies that can be minted for each Template.

Describe the solution you'd like
Here are the most obvious solutions based on CryptoKitties and TopShot codebases:

1. Add the retired flag to the Template struct.
   However, the side effect of it would be passing that information to the Dappy since the data field on a Dappy is a Template.

2. A common approach seems to be a dictionary of totals per Template. For example:

access(self) var mintCountPerTemplate: {UInt32: UInt32}

However, the Template struct itself seems to be a more logical place to keep track of the minted Dappies count.

3. Add the maxQuantity flag to the Template struct itself similar to the suggested place for the retired flag above.
   However, the same problem as in 1 above. That information will be passed on to the Dappy via data and that's not a good place for it.

Describe alternatives you've considered

Solution 1: Introduce a DappyData struct and move all the current Template fields there. Also, add template-specific fields to the Template struct.

public struct DappyData {
    pub let templateID: UInt32
    pub let dna: String
    pub let name: String
    pub let price: UFix64
...
}

pub struct Template {
    pub let templateID: UInt32
    pub let data: DappyData
    pub let maxQuantity: UInt32
    access(self) retired: Bool
    access(self) mintCount: UInt32
...
}

pub resource Dappy {
    pub let id: UInt64  // Global unique NFT ID
    pub let serialNumber: UInt32  // Based on number of Dappies minted with this template
    pub let data: DappyData
...
}

Solution 2:

pub struct Template {
    pub let templateID: UInt32
    pub let dna: String
    pub let name: String
    pub let price: UFix64
    pub let maxQuantity: UInt32
    access(self) retired: Bool
    access(self) mintCount: UInt32
...
}
pub resource Dappy {
    pub let id: UInt64  
    pub let templateID: UInt32
    pub let serialNumber: UInt32
...
}

These are the two alternative solutions for all 3 points above. However, I'm afraid I'm overlooking something and would like your opinion on it. For example,

1. I understand that having the access(self) access modifier for both retired and mintCount fields keeps them secure so nobody can do something like:

DappyContract.templates[templateID]!.retired = true

However, what would be the best way to update these values for Admins only then? Could you point me to some examples?

2. As a side effect of Solution 1 I would need to introduce the dappyDatas dictionary to keep track of data for all Dappies. I would like to avoid doing so.

Could you please provide your opinion on the best way to restructure the code based on the Template functionality expansion I've described above?

Additional context
Thanks for putting together CryptoDappy project and, especially, recording videos and explaining how everything fits together. I'm just trying to find the best place to ask questions similar to the ones above and I hope this is it.