Multiple TokenURI URL in one smart contract

Question

I have a doubt wich is if its possible to have different mint functions pointing to different tokenURI.

Lets say i have 2 mint functions and 2 variables called tokenURI1 and TokenURI2 just like this:

String tokenURI1 = ipfs://test1;
String TokenURI2 = ipfs://test2;

 function mint1(uint256 _mintAmount) public payable {
    _safeMint(_msgSender(),_mintAmount);
  }

 function mint2(uint256 _mintAmount) public payable {
    _safeMint(_msgSender(),_mintAmount);
  }

It is possible to if someone mint in the mint1 function that saves in the memory the url of the tokenURI1 with that token, and if someones mint in the mint2 function that saves in the memory the url of the tokenURI2?

The idea of this is create multiple mint functions in just one smart contract with different images but remaining in the same collection.it is possible to do? how to do that?

Answer 1

It should be possible. For example the OpenZeppelin implementation allows overriding tokenURI(tokenId) function and return the corresponding URI depending on the tokenId.

enum TokenType { Type1, Type2 }

mapping (uint256 => TokenType) tokenType;

function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {
    if (tokenType[tokenId] == TokenType.Type1) {
        return string(abi.encodePacked(tokenURI1, tokenId.toString()));
    } else {
        return string(abi.encodePacked(tokenURI2, tokenId.toString()));
    }
}

Answer 2

It's absolutely possible.

My contract does exactly this. 100%

Allows the owner to - after deployment - add volumes, and correspond tokens to those volumes, that are then minted cleanly on our dApp (and of course more rudimentary in contract itself), based on what volume the minter has chosen. Each volume gets its own associated merkle root as well, in order to whitelist every volume differently, and separate.

You have one deployed contract, with the appearance and control of numerous collections thereafter, all falling under the same deployment address.

You can see it here currently (in its latest test performance;

https://goerli.etherscan.io/address/0x94793fedc87ca4f42fbafee3807709522f5f9b11