Cette page a été traduite par l'API Cloud Translation.

Mapper des composants à un code existant

Les développeurs peuvent personnaliser le processus de génération de code en fournissant un mappage entre un package UI et un composant de code existant au lieu du code généré. Cela s'avère utile lorsque l'implémentation existante comporte des fonctionnalités qui ne peuvent pas être réalisées par le code généré, comme une animation ou un comportement complexe (un menu déroulant, par exemple).

Les développeurs spécifient comment mapper des composants à l'aide d'un fichier de mappage. Un fichier de mappage indique au générateur de code, au minimum, comment atteindre le composable cible. pour créer le bon code client.

Présentation des composants mappés
diagramme

Voici un exemple :

Dans Figma, un concepteur crée un composant Card qui contient une instance. d'un composant Play Bar, regroupe les deux composants et les envoie développeur.

Lorsque le développeur importe les packages UI de Figma, deux répertoires sont créé dans ui-packages: card et play_bar. Lorsqu'il compile le projet, deux fonctions modulables sont créées : Card et PlayBar. En général, comme Card contient une instance de Play Bar dans Figma, dans le code, la fonction modulable Card contient un appel au composable PlayBar.

Cependant, le graphiste et le développeur souhaitent que Card utilise à la place un composable existant, MyExistingPlaybar, dont la fonctionnalité est difficile à décrire dans Figma. Le développeur ajoute donc un fichier de mappage appelé play_bar.json. qui mappe le package UI play_bar à MyExistingPlaybar:

{
    "target": "MyExistingPlaybar",
    "package": "com.example.myApp"
}

Désormais, lorsque le développeur compile le projet, Card appelle MyExistingPlaybar au lieu de PlayBar. Notez que les paramètres de MyExistingPlaybar et de PlayBar doivent être identiques (bien qu'il puisse y avoir quelques différences, comme décrit dans les directives supplémentaires ci-dessous).

Fichier de mappage

Dans vos projets Android Studio, les fichiers de mappage sont ajoutés sous ui-package-resources/mappings à côté du dossier ui-packages. Apparence du relais pour mapper des fichiers pendant la compilation.

Fichier de mappage dans le projet
vue

Générer un fichier de mappage

Relay peut générer un fichier de mappage pour tout package UI importé. Suivre ces étapes:

Effectuez un clic droit sur le dossier du package ou sur n'importe quel fichier dans la cible ui-package. . Sélectionnez Générer un fichier de mappage.
Configurez les options suivantes dans la boîte de dialogue:
- File location (Emplacement du fichier) : définit l'emplacement du fichier de mappage généré.
- Target composable (Composable cible) : définit le composable personnalisé qui est utilisé à la place. à la place du composable généré. Vous avez la possibilité d'utiliser un ou en créer un depuis la boîte de dialogue. Création d'un élément crée un composable avec les mêmes paramètres que ceux définis dans d'UI.
Remarque :Le composable cible doit commencer par une lettre majuscule.
- Fichier généré:définit generateImplementation et generatePreview dans le fichier de mappage. Consultez la section Mapper le contenu des fichiers. ci-dessous pour en savoir plus.
Cliquez sur Générer un fichier de mappage. Un nouveau fichier de mappage est créé dans Dossier ui-package-resources/mapping avec les configurations spécifiées.

Vous pouvez également ouvrir la boîte de dialogue Generate mapping file (Générer un fichier de mappage) à partir de Relay du module de package en procédant comme suit:

Cliquez sur n'importe quel fichier pour un package UI dans la cible ui-package .
Si la fenêtre de l'outil Relay ne s'ouvre pas automatiquement, cliquez sur l'icône Relay pour ouvrir la fenêtre.
Cliquez sur le bouton Generate mapping file (Générer le fichier de mappage) sous Package Options (Options du package).

Remarque :Si un fichier de mappage existe pour le package UI sélectionné, un lien pour l'ouvrir le fichier s'affiche à la place.

Nom du fichier de mappage

Le nom d'un fichier de mappage doit correspondre au nom du dossier du package UI correspondant au composant qu'il remplace. play_bar.json mappe donc le package UI du dossier ui-packages/mappings à un composant de code existant.

Contenu du fichier de mappage

Le fichier de mappage contient les propriétés suivantes:

target : (obligatoire) nom de votre fonction composable personnalisée. Par par défaut, il s'agit du nom de la fonction créée par le code généré.
```
"target" : "CustomComposableName"
```
package (obligatoire) : nom du package contenant votre composable personnalisé. po. Par défaut, il s'agit du package de la fonction créée par du code source.
```
"package" : "com.example.podcastapp.ui.components"
```
generateImplementation (facultatif) : vrai ou faux. Si la valeur est "true", une l'implémentation de ce package UI est tout de même créée dans le code généré . Si la valeur est "false", l'implémentation n'est pas créée. C'est la valeur par défaut.
```
"generateImplementation" : true
```
generatePreviews (facultatif) : vrai ou faux. Si la valeur est "true", un aperçu du le composant personnalisé mappé est créé dans le fichier de code généré. Si "false", non un aperçu est créé. C'est la valeur par défaut.
```
"generatePreviews" : true
```

Variantes mappées

Si un composant Figma comporte des variantes, le composable généré contient des énumérations qui encodent la variante (comme décrit dans la section Gérer la conception Variantes). Si vous souhaitez mapper un composant Figma avec des variantes à code existant, il doit être mappé à un composable qui accepte les mêmes paramètres en tant que composable généré. Par exemple, pour un composant Figma appelé Chip. avec une variante dont la propriété est ChipType, le composable généré par Chip. signature se présente comme suit:

@Composable
fun Chip(
    modifier: Modifier = Modifier,
    chipType: ChipType = ChipType.Red,
    chipText: String
) { ... }

Si vous souhaitez que le composant Figma Chip corresponde à un MyChip existant la signature de MyChip doit avoir la même signature que celle de composable généré (en supposant qu'aucune directive supplémentaire n'est spécifiée). D'un point de vue conceptuel, cela indique que le composant de code existant est compatible avec les mêmes variantes de conception que le composant Figma.

Instructions supplémentaires

Par exemple, si la fonction composable que vous souhaitez cibler possède les éléments suivants : signature:

@Composable
fun MyChip(
    modifier: Modifier = Modifier,
    chipType: ChipType = ChipType.Red,
    description: String  // instead of chipText
) { ... }

Vous pouvez ajouter au fichier de mappage un bloc fieldMappings qui affecte la façon dont paramètres sont mappés. Dans ce cas, il contient un mappage à partir de chipText. dans Chip au paramètre description dans MyChip.

{
    "target": "MyChip",
    "package": "com.example.myApp",
    "fieldMappings": [
        {
            "type": "parameter",
            "source": "chipText",
            "target": "description"
        }
    ]
}

Les types du bloc fieldMappings sont les suivants :

parameter: mappe un champ de package UI à un paramètre de code.
- source: nom du paramètre tel que spécifié dans le package UI.
- target : nom du paramètre tel que spécifié dans le composant du code cible.
lambda: mappe un champ de package UI à un lambda de contenu.
- source: nom du paramètre tel que spécifié dans le package UI.
- target : nom du paramètre tel que spécifié dans le composant du code cible.
modifier: mappe un champ de package UI à une méthode de modificateur.

Remarque :Ce type de mappage est en cours d'incubation, en particulier la gestion habilitations du récepteur.
- source: nom du paramètre tel que spécifié dans le package UI.
- method: méthode de l'objet Modifier à appeler dans du code généré.
- parameter : nom du paramètre dans la méthode Modifier spécifiée.
- library : nom du package qualifié à importer pour accéder à la méthode Modifier.
- scope : l'une des deux valeurs suivantes pour indiquer le champ d'application du modificateur :
- any : le modificateur peut être utilisé dans n'importe quel champ d'application du récepteur.
- relay: le modificateur doit être utilisé dans le champ d'application du récepteur de l'objet RelayContainer.

Recommandations personnalisées

Remarque: Le texte du lien s'affiche lorsque JavaScript correspond à désactivé *. Assistance différents écran tailles d'écran *. Imbriqué package d'instances *. Versions