Los desarrolladores pueden personalizar el proceso de generación de código si brindan una asignación entre un paquete de IU y un componente de código existente, en lugar del código generado. Esto es beneficioso cuando la implementación existente tiene funciones que no se pueden lograr con el código generado, como animación o comportamiento complejo (como un menú desplegable).
Los desarrolladores especifican cómo asignar componentes mediante un archivo de asignación. Un archivo de asignación Le indica al generador de código, como mínimo, cómo alcanzar el elemento componible de destino. para que se pueda crear el código de cliente correcto.
A continuación, se muestra un ejemplo:
En Figma, un diseñador crea un componente Card que contiene una instancia. de un componente de Play Bar, empaqueta ambos componentes y los envía a una desarrollador.
Cuando el desarrollador importa los paquetes de IU desde Figma, se muestran dos directorios
creado en ui-packages
: card
y play_bar
. Cuando compilan el proyecto, se crean dos funciones de componibilidad: Card
y PlayBar
. Por lo general, debido a que Card contiene una instancia de Play Bar en Figma, en el código, la función de componibilidad Card
contiene una llamada al elemento componible PlayBar
.
Sin embargo, el diseñador y el desarrollador quieren que Card
use un elemento componible MyExistingPlaybar
existente, que tiene una funcionalidad difícil de describir en Figma. Por lo tanto, el desarrollador agrega un archivo de asignación llamado play_bar.json
que asigna el paquete de IU play_bar
a MyExistingPlaybar
:
{
"target": "MyExistingPlaybar",
"package": "com.example.myApp"
}
Ahora, cuando el desarrollador compila el proyecto, Card
llama a MyExistingPlaybar
en lugar de PlayBar
. Ten en cuenta que MyExistingPlaybar
debe tener los mismos parámetros que PlayBar
(aunque puede haber algunas diferencias, como se describe en Directivas adicionales a continuación).
Archivo de asignación
En tus proyectos de Android Studio, los archivos de asignación se agregan en ui-package-resources/mappings
junto a la carpeta ui-packages
. Aspecto de Relay
para asignar archivos durante la compilación.
Genera un archivo de asignación
Relay puede generar un archivo de asignación para cualquier paquete de IU importado. Seguir pasos:
Haz clic con el botón derecho en la carpeta del paquete o en cualquier archivo dentro del
ui-package
de destino. carpeta. Selecciona Generate mapping file.Configura las siguientes opciones en el cuadro de diálogo:
Ubicación del archivo: Establece la ubicación del archivo de asignación generado.
Elemento componible de destino: Establece el elemento personalizado que se usa en su lugar. en lugar del elemento componible generado. Tienes la opción de usar un componible existente o crear uno nuevo desde el diálogo. Crear un nuevo archivo componible crea un elemento componible con los mismos parámetros que se definen en la Paquete de IU.
- Archivo generado: Establece el
generateImplementation
y OpcionesgeneratePreview
en el archivo de asignación. Consulta Cómo asignar contenido de archivos. a continuación para obtener más detalles.
Haz clic en Generate mapping file. Se crea un nuevo archivo de asignación Carpeta
ui-package-resources/mapping
con los parámetros de configuración especificados.
También puedes abrir el diálogo Generate mapping file desde Relay del módulo de paquetes con estos pasos:
Haz clic en cualquier archivo para obtener un paquete de IU dentro del
ui-package
de destino. carpeta.Si la ventana de herramientas Relay no se abre automáticamente, haz clic en el ícono Relay. para abrir la ventana.
Haz clic en el botón Generate mapping file en Package Options.
Nombre del archivo de asignación
El nombre de un archivo de asignación determinado debe coincidir con el nombre de la carpeta del paquete de IU para el componente que reemplaza. Por lo tanto, play_bar.json
asigna el paquete de IU de la carpeta ui-packages/mappings
a un componente de código existente.
Cómo asignar contenidos de archivos
El archivo de asignación contiene las siguientes propiedades:
target: Es el nombre de la función de componibilidad personalizada (obligatorio). De default, este es el nombre de la función creada por el código generado.
"target" : "CustomComposableName"
package: (obligatorio): Es el nombre del paquete en el que se encuentra el elemento componible personalizado. en el que te etiquetaron. De forma predeterminada, este es el paquete de la función creada por los código.
"package" : "com.example.podcastapp.ui.components"
generateImplementation: (Opcional) Es verdadero o falso. Si es verdadero, un implementación de este paquete de IU aún se crea en el código generado . Si es falso, no se crea la implementación. De forma predeterminada, esto es verdadero.
"generateImplementation" : true
generatePreviews: (opcional) verdadero o falso. Si es verdadero, se mostrará una vista previa del el componente personalizado asignado se crea en el archivo de código generado. Si es falso, no se crea la vista previa. De forma predeterminada, esto es verdadero.
"generatePreviews" : true
Variantes asignadas
Si un componente de Figma tiene variantes, el elemento componible generado contiene enum. parámetros que codifican la variante (como se describe en el artículo Diseño de administración Variantes). Si deseas asignar un componente de Figma con variantes a código existente, debe asignarse a un elemento componible que tome los mismos parámetros como el elemento componible generado. Por ejemplo, para un componente de Figma llamado Chip con una variante cuya propiedad es ChipType, el elemento componible generado de Chip firma se ve así:
@Composable
fun Chip(
modifier: Modifier = Modifier,
chipType: ChipType = ChipType.Red,
chipText: String
) { ... }
Si deseas que el componente Chip de Figma se asigne a un MyChip
existente
componible, la firma de MyChip
debe tener la misma firma que el
elemento componible generado (suponiendo que no se especifican directivas adicionales)
Conceptualmente, esto sugiere que el componente de código existente es capaz de las mismas variantes de diseño que el componente de Figma.
Directivas adicionales
Por ejemplo, si la función de componibilidad a la que quieres orientarte tiene lo siguiente: firma:
@Composable
fun MyChip(
modifier: Modifier = Modifier,
chipType: ChipType = ChipType.Red,
description: String // instead of chipText
) { ... }
Puedes agregar un bloque fieldMappings
al archivo de asignación que afecta la forma
se asignan los parámetros. En este caso, contiene una asignación del chipText
.
de Chip
al parámetro description
en MyChip
.
{
"target": "MyChip",
"package": "com.example.myApp",
"fieldMappings": [
{
"type": "parameter",
"source": "chipText",
"target": "description"
}
]
}
Los tipos para el bloque fieldMappings
incluyen los siguientes:
parameter
: Asigna un campo de paquete de IU a un parámetro de código.source
: Es el nombre del parámetro como se especifica en el paquete de IU.target
: Es el nombre del parámetro, como se especifica en el componente del código de destino.
lambda
: Asigna un campo de paquete de IU a una lambda de contenido.source
: Es el nombre del parámetro como se especifica en el paquete de IU.target
: Es el nombre del parámetro, como se especifica en el componente del código de destino.
modifier
: Asigna un campo de paquete de IU a un método modifier.source
: Es el nombre del parámetro como se especifica en el paquete de IU.method
: Es el método del objeto Modifier que se debe invocar en código generado.parameter
: Es el nombre del parámetro dentro del método Modifier especificado.library
: Es el nombre del paquete calificado que se importará para acceder al método Modifier.scope
: Es uno de dos valores para indicar el alcance del Modifier:any
: El modificador se puede usar en cualquier alcance del receptor.relay
: Se debe usar el modificador en el alcance del receptor de la interfaz de Relay.RelayContainer
.
Recomendaciones para ti
- Nota: El texto del vínculo se muestra cuando JavaScript es desactivada * Asistencia diferentes pantalla tamaños * Anidado paquete de instancias * Lanzamientos