[#CALENDRIER DE L'AVENT 10/25]
25 jours pour apprendre à développer des Smart Contracts en #Solidity 🔥
Jour 10 / 25 :
Création #ERC721 : Les variables 💻
🧵
Tweet précédent
🔽
Bonjour à tous ! Nouveau sujet du jour : les variables de notre contrat ERC721 !
Mais avant ça, il est temps de définir notre objectif avec ce contrat…
Ce que je propose (vous pouvez adapter en fonction de ce que vous souhaitez) :
- Une supply de 20 NFTs
- Une vente en whitelist au prix de 0.5 MATIC (max 10 NFTs)
- Une vente en public au prix de 1 MATIC
- Pas plus de 1 mint par whitelist
Une fois que tout cela sera mis en place, vous aurez les clefs principales pour faire un contrat ERC721 standard ! Commençons à rajouter nos variables.
Si vous avez raté le jour précédent, vous pouvez repartir du code présent dans le dossier “contracts/Jour10” !
Aujourd’hui nous allons commencer par déclarer l’utilisation de “Counters” et “Strings”.
“Counters” s’initialise pour son propre type, “Counter”.
"Strings" s'utilise avec le type “uint” pour convertir des entiers.
Nous allons déclarer le compteur qui servira à incrémenter les IDs de NFT.
Il s’agit d’une variable nommée “_tokenIds” qui est du type “Counter” de la librairie.
On va le définir de type “private” car inutile de laisser cette variable accessible depuis une fonction publique.
Note : par définition, on essaie de nommer les variables privées grâce à un underscore en début de nom, d'où le "_tokenIds".
Nous allons maintenant déclarer une variable “Step” de type “enum”, ceci permet de créer un type de variable avec plusieurs états prédéfini.
Nous définissons les étapes de vente avec
0 : “SaleNotStarted”,
1 : “WhitelistSale”,
etc.
Tout ceci sera stocké dans une autre variable.
Cette autre variable c’est la variable “currentStep” de type “Step”.
Cette est “public” car on souhaite que notre application et nos utilisateurs puissent avoir accès à l’état d’avancement de la vente.
Elle contient donc la valeur (0/1/2/3) de l’étape en cours.
On passe rapidement sur la variable d’après, c’est une variable “public” pour que notre dApp puisse la lire facilement (et les utilisateurs).
Il s’agit du stockage de la route de Merkle.
Pour le moment c’est un peu flou, nous en reparlerons au moment de parler des whitelists !
Étape suivante, la définition du nombre max de NFTs et le nombre max disponible pendant la phase de whitelist.
Ces deux variables sont des entiers constants, car nous ne souhaitons jamais les modifier.
Elles sont aussi “public”, encore pour des appelles de la potentielle dApp.
Nous devons définir un prix pour la vente “whitelist” et un pour la “public”.
Ce sont aussi des entiers, mais pas des constantes, car nous pourrions avoir envie de les changer en cas de forte variation du prix le jour du mint par exemple.
Pour rappel, 0.5 ether = 0.5 MATIC.
La variable suivante est un mapping qui permet d’associer un nombre à une adresse.
Le but ici est d’enregistrer le nombre de mint qu’effectue une adresse pendant la whitelist pour être sur qu’il ne puisse mint qu’une seule fois.
Encore une fois, il est de type “public”.
Dernière variable et dernière étape pour aujourd’hui, il s’agit de la variable qui va stocker la base de notre URI (lien IPFS) vers les métadonnées.
Nous reparlerons de cette variable quand nous aborderons le sujet des “metadatas” de nos NFTs !
Vous avez initialisé l'ensemble des variables nécessaires pour notre contrat de NFT !
Demain, nous passerons au constructeur et aux premières fonctions !
N'hésitez pas à vous abonner pour ne pas rater les jours qui arrivent 🔥
Passez une bonne journée, à demain !👋
Share this Scrolly Tale with your friends.
A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.