final contract fns

[dcsan]

(posting for @keepRunning )

this is what I have. Should suffice for the UI for now. I need to refactor and some checks, but the signatures should remain the same.

• rollToMint(address to) - to mint letter
• claimToken(uint256 tokenId, string memory tokenURI)
• getDna(uint256 tokenId) public view returns (uint256)
• isClaimed(uint256 tokenId) public view returns (bool) - check is claimed
• mintWord(address to, string memory tokenURI,uint256[] memory tokenIds, uint256[] memory rows,uint256[] memory cols)
• saveWord(uint256 tokenId,string memory tokenURI,uint256[] memory tokenIds,uint256[] memory rows,uint256[] memory cols) - Save/Update word after mint -GetWord(uint256 tokenId) returns (uint256[] memory tokenIds, uint256[] memory rows, uint256[] memory cols) Still getting to know rarible. I expect to have some integration done tomorrow.

[dcsan]

I think getInfo can return both DNA and isClaimed status, so i can get all the info in one call for rendering.

would this return a struct, or two variables? I'm not clear how to return structs or I could look into this. @keepRunning

[keepRunning]

I can add a getTokenInfo(tokenId) returning array of two values if you think it will help. We need to reduce overall calls to api. We faced having too many infura calls in the previous app.

[dcsan]

yeah that sounds good. an array of different types though? wow, solidity is so flexible :D

this is also called once PER LETTER so it's a lot of events...

maybe I can cache it locally but hard to know when I can cache... if there's a claim event i could do some other stuff which is event based, but react will try to render everything. these are only read requests so ... ?

there's a lot of chatter in the app that i think is also causing re-renders.

for claimed items all that info should be in the metadata on IPFS which comes in with the object.

[keepRunning]

We have to reduce refresh time. It will be chatty unless use our own graph server/rarible apis. We can't avoid it. Technically, we don't need any ipfs info since we use dna, claim status, Word structure everything from contract. We can definitely cache/local-storage the Letters since they don't change after mint/claim. Even words might be fixed after mint.

[dcsan]

it's pretty fast right now, but just on a local graph. idno if we'll have time to optimize in next 2 days tho... still lots to get on the basics.

[tomosaigon]

the chatter is happening on block updates, not page refresh, therefore caching to browser storage will only prevent requests once.

maybe a better way than listening for updates but that's how the scaffold is set up to work and optimizing that is probably not something we have time for.

[tomosaigon]

mentioned yesterday in discord:

saveWord(uint256 tokenId,string memory tokenURI,uint256[] memory tokenIds,uint256[] memory rows,uint256[] memory cols) - Save/Update word after mint

probably no need for this. TokenURI is saved during word's mint. No need to ever update it.

[tomosaigon]

One thing to note: Letters and Words can be rendered just from reading the blockchain. HOWEVER, there's also small bits of data in metadata.json on ipfs: name is the main one. We can ignore the name if there's no time to connect the rest up.