From ca8ad858c81c144719ff587b3623a4def7e76a78 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= Date: Sun, 24 Dec 2023 12:00:59 -0500 Subject: [PATCH] New translations creating-a-subgraph.mdx (French) --- .../fr/developing/creating-a-subgraph.mdx | 444 +++++++++--------- 1 file changed, 225 insertions(+), 219 deletions(-) diff --git a/website/pages/fr/developing/creating-a-subgraph.mdx b/website/pages/fr/developing/creating-a-subgraph.mdx index 6dd9f640df22..cf0cfa0da053 100644 --- a/website/pages/fr/developing/creating-a-subgraph.mdx +++ b/website/pages/fr/developing/creating-a-subgraph.mdx @@ -14,7 +14,7 @@ Un subgraph se constitue des fichiers suivants : - `Mappages AssemblyScript` : [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) qui traduit les données d'événement en entités définies dans votre schéma (par exemple `mapping.ts` dans ce tutoriel) -> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/deploying/subgraph-studio-faqs/#2-how-do-i-create-an-api-key). It is recommended that you [add signal](/network/curating/#how-to-signal) to your subgraph with at least [10,000 GRT](/network-transition-faq/#how-can-i-ensure-that-my-subgraph-will-be-picked-up-by-indexer-on-the-graph-network). +> Pour pouvoir utiliser votre subgraph sur le réseau décentralisé de The Graph, vous aurez besoin de [créer une clé API](/deploying/subgraph-studio-faqs/#2-how-do-i-create-an-api-key). Il est recommandé d'[ajouter un signal](/network/curating/#how-to-signal) à votre subgraph avec au moins [10,000 GRT](/network-transition-faq/#how-can-i-ensure-that-my-subgraph-will-be-picked-up-by-indexer-on-the-graph-network). Avant d'aller en détail à propos du contenu du manifeste, installons l'[interface de ligne de commande de TheGraph](https://github.com/graphprotocol/graph-cli). Nous en aurons besoin pour la création et le déploiement du subgraph. @@ -164,9 +164,9 @@ Les entrées importantes à mettre à jour pour le manifeste sont : - `dataSources.mapping.eventHandlers` : répertorie les événements de contrat intelligent auxquels ce subgraph réagit et les gestionnaires du mappage —./src/mapping.ts dans l'exemple qui transforment ces événements en entités dans le magasin. -- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store. +- `dataSources.mapping.callHandlers` : répertorie les fonctions de contrat intelligent auxquelles ce smubgraph réagit et les gestionnaires du mappage qui transforment les entrées et sorties en appels de fonction en entités dans le magasin. -- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract. +- `dataSources.mapping.blockHandlers` : répertorie les blocs auxquels ce subgraph réagit et les gestionnaires du mappage à exécuter lorsqu'un bloc est ajouté à la chaîne. Sans filtre, le gestionnaire de bloc sera exécuté à chaque bloc. Un filtre d'appel facultatif peut être fourni en ajoutant un champ `filter` avec `kind: call` au gestionnaire. Cela n'exécutera le gestionnaire que si le bloc contient au moins un appel au contrat de source de données. Un seul subgraph peut indexer les données de plusieurs contrats intelligents. Ajoutez une entrée pour chaque contrat à partir duquel les données doivent être indexées dans le tableau `dataSources`. @@ -174,11 +174,11 @@ Les déclencheurs d'une source de données au sein d'un bloc sont classés à l' 1. Les déclencheurs d'événements et d'appels sont d'abord classés par index de transaction au sein du bloc. 2. Les déclencheurs d'événements et d'appels au sein d'une même transaction sont classés selon une convention : les déclencheurs d'événements d'abord, puis les déclencheurs d'appel, chaque type respectant l'ordre dans lequel ils sont définis dans le manifeste. -3. Block triggers are run after event and call triggers, in the order they are defined in the manifest. +3. Les déclencheurs de bloc sont exécutés après les déclencheurs d'événement et d'appel, dans l'ordre dans lequel ils sont définis dans le manifeste. Ces règles de commande sont susceptibles de changer. -### Getting The ABIs +### Obtenir les ABI Le(s) fichier(s) ABI doivent correspondre à votre(vos) contrat(s). Il existe plusieurs façons d'obtenir des fichiers ABI : @@ -201,32 +201,32 @@ Avec The Graph, vous définissez simplement les types d'entités dans `schema.gr L'entité `Gravatar` ci-dessous est structurée autour d'un objet Gravatar et constitue un bon exemple de la façon dont une entité pourrait être définie. ```graphql -tapez Gravatar @entity(immuable : true) { - identifiant : octets ! - propriétaire : octets - displayName : chaîne - imageUrl : chaîne - accepté : booléen +type Gravatar @entity(immutable: true) { + id: Bytes! + owner: Bytes + displayName: String + imageUrl: String + accepted: Boolean } ``` -### Bad Example +### Mauvais exemple Les exemples d'entités `GravatarAccepted` et `GravatarDeclined` ci-dessous sont basés sur des événements. Il n'est pas recommandé de mapper des événements ou des appels de fonction à des entités 1:1. ```graphql -tapez GravatarAccepted @entity { - identifiant : octets ! - propriétaire : octets - displayName : chaîne - imageUrl : chaîne +type GravatarAccepted @entity { + id: Bytes! + owner: Bytes + displayName: String + imageUrl: String } -tapez GravatarDeclined @entity { - identifiant : octets ! - propriétaire : octets - displayName : chaîne - imageUrl : chaîne +type GravatarDeclined @entity { + id: Bytes! + owner: Bytes + displayName: String + imageUrl: String } ``` @@ -238,9 +238,9 @@ Les champs d'entité peuvent être définis comme obligatoires ou facultatifs. L Null value resolved for non-null field 'name' ``` -Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`. +Chaque entité doit avoir un champ `id`, qui doit être de type `Bytes !` ou `String !`. Il est généralement recommandé d'utiliser `Bytes !`, à moins que l'`identifiant` ne contienne du texte lisible par l'homme, car les entités avec des identifiants `Bytes !` seront plus rapides à écrire. et interrogez comme ceux avec un `String!` `id`. Le champ `id` sert de clé primaire et doit être unique parmi toutes les entités du même type. Pour des raisons historiques, le type `ID!` est également accepté et est synonyme de `String!`. -For some entity types the `id` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id)` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`. +Pour certains types d'entités, l'`id` est construit à partir des identifiants de deux autres entités ; cela est possible en utilisant `concat`, par exemple `let id = left.id.concat(right.id)` pour former l'identifiant à partir des identifiants de `gauche et à droite`. De même, pour construire un identifiant à partir de l'identifiant d'une entité existante et d'un compteur `count`, `let id = left.id.concatI32(count)` peut être utilisé. La concaténation est garantie pour produire des identifiants uniques tant que la longueur de `left` est la même pour toutes ces entités, par exemple, parce que `left.id` est une `adresse `. ### Types scalaires intégrés @@ -248,19 +248,19 @@ For some entity types the `id` is constructed from the id's of two other entitie Nous prenons en charge les scalaires suivants dans notre API GraphQL : -| Type | Description | -| --- | --- | -| `Octets` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. | -| `String` | Scalaire pour les valeurs `chaîne`. Les caractères nuls ne sont pas pris en charge et sont automatiquement supprimés. | -| `Boolean` | Scalar pour `boolean` values. | -| `Int` | La spécification GraphQL définit `Int` pour avoir une taille de 32 octets. | -| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. | -| `BigInt` | Grands entiers. Utilisé pour les types `uint32`, `int64`, `uint64`, ..., `uint256` d'Ethereum. Remarque : Tout ce qui se trouve en dessous de `uint32`, tel que `int32`, `uint24` ou `int8`, est représenté par `i32 **Remarque :** Une nouvelle source de données traitera uniquement les appels et les événements du bloc dans lequel elle a été créée et de tous les blocs suivants, mais ne traitera pas les données historiques, c'est-à-dire les données. qui est contenu dans les blocs précédents. -> +> > Si les blocs précédents contiennent des données pertinentes pour la nouvelle source de données, il est préférable d'indexer ces données en lisant l'état actuel du contrat et en créant des entités représentant cet état au moment de la création de la nouvelle source de données. ### Data Source Context @@ -676,13 +676,13 @@ export function handleNewExchange(event: NewExchange): void { } ``` -Inside a mapping of the `Exchange` template, the context can then be accessed: +A l'intérieur d'un mappage du modèle `Exchange`, le contexte est alors accessible : ```typescript -importer { dataSource } depuis '@graphprotocol/graph-ts' +import { dataSource } from '@graphprotocol/graph-ts' -laissez contexte = dataSource.context() -laissez tradingPair = context.getString('tradingPair') +let context = dataSource.context() +let tradingPair = context.getString('tradingPair') ``` Il existe des setters et des getters comme `setString` et `getString` pour tous les types de valeur. @@ -692,38 +692,38 @@ Il existe des setters et des getters comme `setString` et `getString` pour tous Le `startBlock` est un paramètre facultatif qui vous permet de définir à partir de quel bloc de la chaîne la source de données commencera l'indexation. La définition du bloc de départ permet à la source de données d'ignorer potentiellement des millions de blocs non pertinents. En règle générale, un développeur de subgraphs définira `startBlock` sur le bloc dans lequel le contrat intelligent de la source de données a été créé. ```yaml -les sources de données: - - genre : ethereum/contrat - nom : ExempleSource - réseau : réseau principal - source: - adresse : '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95' - abi : Exemple de contrat - bloc de démarrage : 6627917 - cartographie : - genre : ethereum/événements - Version api : 0.0.6 - langage : wasm/assemblyscript - fichier : ./src/mappings/factory.ts - entités : - - Utilisateur - abis : - - nom : ExempleContrat - fichier : ./abis/ExampleContract.json - Gestionnaires d'événements : - - événement : NewEvent(adresse,adresse) - gestionnaire : handleNewEvent +dataSources: + - kind: ethereum/contract + name: ExampleSource + network: mainnet + source: + address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95' + abi: ExampleContract + startBlock: 6627917 + mapping: + kind: ethereum/events + apiVersion: 0.0.6 + language: wasm/assemblyscript + file: ./src/mappings/factory.ts + entities: + - User + abis: + - name: ExampleContract + file: ./abis/ExampleContract.json + eventHandlers: + - event: NewEvent(address,address) + handler: handleNewEvent ``` > **Remarque :** Le bloc de création de contrat peut être rapidement consulté sur Etherscan : -> +> > 1. Recherchez le contrat en saisissant son adresse dans la barre de recherche. > 2. Cliquez sur le hachage de la transaction de création dans la section `Contract Creator`. -> 3. Load the transaction details page where you'll find the start block for that contract. +> 3. Chargez la page des détails de la transaction où vous trouverez le bloc de départ de ce contrat. -## Call Handlers +## Gestionnaires d'appels -While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured. +Bien que les événements constituent un moyen efficace de collecter les modifications pertinentes apportées à l'état d'un contrat, de nombreux contrats évitent de générer des journaux pour optimiser les coûts du gaz. Dans ces cas, un subgraph peut s'abonner aux appels effectués vers le contrat de source de données. Ceci est réalisé en définissant des gestionnaires d'appels faisant référence à la signature de la fonction et au gestionnaire de mappage qui traitera les appels à cette fonction. Pour traiter ces appels, le gestionnaire de mappage recevra un `ethereum.Call` comme argument avec les entrées et sorties saisies de l'appel. Les appels effectués à n'importe quelle profondeur dans la chaîne d'appels d'une transaction déclencheront le mappage, permettant de capturer l'activité avec le contrat de source de données via des contrats proxy. Les gestionnaires d'appels ne se déclencheront que dans l'un des deux cas suivants : lorsque la fonction spécifiée est appelée par un compte autre que le contrat lui-même ou lorsqu'elle est marquée comme externe dans Solidity et appelée dans le cadre d'une autre fonction du même contrat. @@ -735,23 +735,25 @@ Pour définir un gestionnaire d'appels dans votre manifeste, ajoutez simplement ```yaml les sources de données: - - genre: ethereum/contrat - nom: Gravité - réseau: réseau principal - source: - adresse: '0x731a10897d267e19b34503ad902d0a29173ba4b1' - abi: Gravité - cartographie: - genre: ethereum/événements - Version api: 0.0.6 - langage: wasm/assemblyscript - entités: -Gravatar - Transaction - abis: - - nom: Gravité - fichier: ./abis/Gravity.json - Gestionnaires d'appels: - - fonction: createGravatar(string,string) - gestionnaire: handleCreateGravatar + - genre : ethereum/contrat + nom: Gravité + réseau : réseau principal + source: + adresse : '0x731a10897d267e19b34503ad902d0a29173ba4b1' + abi : Gravité + cartographie : + genre : ethereum/événements + Version api : 0.0.6 + langage : wasm/assemblyscript + entités : + -Gravatar + - Transaction + abis : + - nom : Gravité + fichier : ./abis/Gravity.json + Gestionnaires d'appels : + - fonction : createGravatar(string,string) + gestionnaire : handleCreateGravatar ``` La `fonction` est la signature de fonction normalisée permettant de filtrer les appels. La propriété `handler` est le nom de la fonction de votre mappage que vous souhaitez exécuter lorsque la fonction cible est appelée dans le contrat de source de données. @@ -761,15 +763,15 @@ La `fonction` est la signature de fonction normalisée permettant de filtrer les Chaque gestionnaire d'appel prend un seul paramètre dont le type correspond au nom de la fonction appelée. Dans l'exemple de subgraph ci-dessus, le mappage contient un gestionnaire lorsque la fonction `createGravatar` est appelée et reçoit un paramètre `CreateGravatarCall` comme argument : ```typescript -importer { CreateGravatarCall } depuis '../generated/Gravity/Gravity' -importer { Transaction } depuis '../generated/schema' - -fonction d'exportation handleCreateGravatar (appel : CreateGravatarCall) : void { - laissez id = call.transaction.hash - let transaction = nouvelle transaction (id) - transaction.displayName = call.inputs._displayName - transaction.imageUrl = call.inputs._imageUrl - transaction.save() +import { CreateGravatarCall } from '../generated/Gravity/Gravity' +import { Transaction } from '../generated/schema' + +export function handleCreateGravatar(call: CreateGravatarCall): void { + let id = call.transaction.hash + let transaction = new Transaction(id) + transaction.displayName = call.inputs._displayName + transaction.imageUrl = call.inputs._imageUrl + transaction.save() } ``` @@ -781,11 +783,11 @@ En plus de s'abonner à des événements de contrat ou à des appels de fonction ### Supported Filters -#### Call Filter +#### Filtre d'appel ```yaml filtre: - genre: appeler + genre : appeler ``` _Le gestionnaire défini sera appelé une fois pour chaque bloc contenant un appel au contrat (source de données) sous lequel le gestionnaire est défini._ @@ -795,28 +797,28 @@ _Le gestionnaire défini sera appelé une fois pour chaque bloc contenant un app L'absence de filtre pour un gestionnaire de bloc garantira que le gestionnaire est appelé à chaque bloc. Une source de données ne peut contenir qu'un seul gestionnaire de bloc pour chaque type de filtre. ```yaml -les sources de données: - - genre : ethereum/contrat - nom: Gravité - réseau : développeur - source: - adresse : '0x731a10897d267e19b34503ad902d0a29173ba4b1' - abi : Gravité - cartographie : - genre : ethereum/événements - Version api : 0.0.6 - langage : wasm/assemblyscript - entités : - -Gravatar - - Transaction - abis : - - nom : Gravité - fichier : ./abis/Gravity.json - gestionnaires de blocs : - - gestionnaire : handleBlock - - gestionnaire : handleBlockWithCallToContract - filtre: - genre : appele +dataSources: + - kind: ethereum/contract + name: Gravity + network: dev + source: + address: '0x731a10897d267e19b34503ad902d0a29173ba4b1' + abi: Gravity + mapping: + kind: ethereum/events + apiVersion: 0.0.6 + language: wasm/assemblyscript + entities: + - Gravatar + - Transaction + abis: + - name: Gravity + file: ./abis/Gravity.json + blockHandlers: + - handler: handleBlock + - handler: handleBlockWithCallToContract + filter: + kind: call ``` #### Filtre d'interrogation @@ -848,13 +850,13 @@ blockHandlers: kind: once ``` -The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing. +Le gestionnaire défini avec le filtre once ne sera appelé qu'une seule fois avant l'exécution de tous les autres gestionnaires. Cette configuration permet au subgraph d'utiliser le gestionnaire comme gestionnaire d'initialisation, effectuant des tâches spécifiques au début de l'indexation. ```ts -fonction d'exportation handleOnce (bloc : ethereum.Block) : void { - laissez data = new InitialData(Bytes.fromUTF8('initial')) - data.data = 'Configurer les données ici' - data.save() +export function handleOnce(block: ethereum.Block): void { + let data = new InitialData(Bytes.fromUTF8('initial')) + data.data = 'Setup data here' + data.save() } ``` @@ -863,12 +865,12 @@ fonction d'exportation handleOnce (bloc : ethereum.Block) : void { La fonction de mappage recevra un `ethereum.Block` comme seul argument. Comme les fonctions de mappage pour les événements, cette fonction peut accéder aux entités de subgraphs existantes dans le magasin, appeler des contrats intelligents et créer ou mettre à jour des entités. ```typescript -importer { ethereum } depuis '@graphprotocol/graph-ts' +import { ethereum } from '@graphprotocol/graph-ts' -fonction d'exportation handleBlock (bloc : ethereum.Block) : void { - laissez l'identifiant = block.hash - laisser l'entité = nouveau bloc (id) - entité.save() +export function handleBlock(block: ethereum.Block): void { + let id = block.hash + let entity = new Block(id) + entity.save() } ``` @@ -892,10 +894,10 @@ Un événement ne sera déclenché que lorsque la signature et le sujet 0 corres Pour ce faire, les gestionnaires d'événements doivent être déclarés dans le manifeste du subgraph avec la nouvelle clé `receipt: true`, qui est facultative et vaut par défaut false. ```yaml -gestionnaires d'événements: - - événement: NewGravatar(uint256,adresse,chaîne,chaîne) - gestionnaire: handleNewGravatar - reçu: vrai +eventHandlers: + - event: NewGravatar(uint256,address,string,string) + handler: handleNewGravatar + receipt: true ``` Dans la fonction de gestionnaire, le reçu est accessible dans le champ `Event.receipt`. Lorsque la clé `receipt` est définie sur `false` ou omise dans le manifeste, une valeur `null` sera renvoyée à la place. @@ -904,12 +906,12 @@ Dans la fonction de gestionnaire, le reçu est accessible dans le champ `Event.r À partir de `specVersion` `0.0.4`, les fonctionnalités de subgraph doivent être explicitement déclarées dans la section `features` au niveau supérieur du fichier manifeste, en utilisant leur `camelCase`, comme indiqué dans le tableau ci-dessous : -| Fonctionnalité | Name | -| --- | --- | -| [Erreurs non fatales](#non-fatal-errors) | `erreursnonfatales` | -| [Recherche en texte intégral](#defining-fulltext-search-fields) | `recherche en texte intégral` | -| [La greffe](#grafting-onto-existing-subgraphs) | `greffage` | -| [IPFS sur les contrats Ethereum](#ipfs-on-ethereum-contracts) | `ipfsOnEthereumContracts` or `nonDeterministicIpfs` | +| Fonctionnalité | Nom | +| --------------------------------------------------------------- | --------------------------------------------------- | +| [Erreurs non fatales](#non-fatal-errors) | `erreursnonfatales` | +| [Recherche en texte intégral](#defining-fulltext-search-fields) | `recherche en texte intégral` | +| [La greffe](#grafting-onto-existing-subgraphs) | `greffage` | +| [IPFS sur les contrats Ethereum](#ipfs-on-ethereum-contracts) | `ipfsOnEthereumContracts` ou `nonDeterministicIpfs` | Par exemple, si un subgraph utilise les fonctionnalités **Recherche en texte intégral** et **Erreurs non fatales** features, le `features` dans le manifeste doit être : @@ -945,7 +947,11 @@ Les erreurs d'indexation sur les subgraphs déjà synchronisés entraîneront, p L'activation des erreurs non fatales nécessite la définition de l'indicateur de fonctionnalité suivant sur le manifeste du subgraph : ```yaml -l'activation des erreurs non fatales nécessite la définition de l'indicateur de fonctionnalité suivant sur le manifeste du subgraph ... +specVersion: 0.0.4 +description: Gravatar for Ethereum +features: + - nonFatalErrors + ... ``` La requête doit également choisir d'interroger les données présentant des incohérences potentielles via l'argument `subgraphError`. Il est également recommandé d'interroger `_meta` pour vérifier si le subgraph a ignoré des erreurs, comme dans l'exemple : @@ -963,20 +969,20 @@ _meta { Si le subgraph rencontre une erreur, cette requête renverra à la fois les données et une erreur graphql avec le message `"indexing_error"`, comme dans cet exemple de réponse : ```graphql -"données": { - "foos": [ - { - "identifiant": "0xdead" - } - ], - "_meta": { - "hasIndexingErrors": vrai - } +"data": { + "foos": [ + { + "id": "0xdead" + } + ], + "_meta": { + "hasIndexingErrors": true + } }, -"les erreurs": [ - { - "message": "erreur_indexation" - } +"errors": [ + { + "message": "indexing_error" + } ] ``` @@ -990,9 +996,9 @@ Un subgraph est greffé sur un subgraph de base lorsque le manifeste du soubgrap ```yaml description: ... -greffer: - base: Qm... # ID de subgraph du subgraph de base - bloc: 7345624 # Numéro de bloc +graft: + base: Qm... # Subgraph ID of base subgraph + block: 7345624 # Block number ``` Lorsqu'un subgraph dont le manifeste contient un bloc `graft` est déployé, Graph Node copiera les données du subgraph `base` jusqu'au `bloc` donné inclus. puis continuez à indexer le nouveau subgraph à partir de ce bloc. Le subgraph de base doit exister sur l'instance Graph Node cible et doit avoir été indexé jusqu'au moins au bloc donné. En raison de cette restriction, le greffage ne doit être utilisé que pendant le développement ou en cas d'urgence pour accélérer la production d'un subgraph équivalent non greffé. @@ -1085,19 +1091,19 @@ Si la relation est 1:1 entre l'entité parent et l'entité de source de données Il s'agit de la source de données qui sera générée lorsqu'un fichier d'intérêt est identifié. ```yaml -modèles: - - nom: TokenMetadata - genre: fichier/ipfs - cartographie: - Version api: 0.0.7 - langage: wasm/assemblyscript - fichier: ./src/mapping.ts - gestionnaire: handleMetadata - entités: - - TokenMétadonnées - abis: - - nom: Jeton - fichier: ./abis/Token.json +modèles : + - nom : TokenMetadata + genre : fichier/ipfs + cartographie : + Version api : 0.0.7 + langage : wasm/assemblyscript + fichier : ./src/mapping.ts + gestionnaire : handleMetadata + entités : + - TokenMétadonnées + abis : + - nom : Jeton + fichier : ./abis/Token.json ``` > Actuellement, les `abis` sont requis, bien qu'il ne soit pas possible d'appeler des contrats à partir de sources de données de fichiers @@ -1160,7 +1166,7 @@ import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates' const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm' //Cet exemple de code concerne un sous-graphe de Crypto coven. Le hachage ipfs ci-dessus est un répertoire contenant les métadonnées des jetons pour toutes les NFT de l'alliance cryptographique. -export function handleTransfer(event: TransferEvent): void { +export function handleTransfer(event : TransferEvent) : void { let token = Token.load(event.params.tokenId.toString()) if (!token) { token = new Token(event.params.tokenId.toString())