Propiedades, variantes y slots: define el contrato del componente

Utiliza propiedades concretas para configurar, variantes para estados o tipos con nombre y slots para contenido que necesita composición. Define las responsabilidades de la estructura. Un sistema de diseño escalable necesita un acuerdo claro sobre lo que puede cambiar cada consumidor, sin crear una variante para cada combinación de contenido.

Separa configuración y composición

Empieza por la decisión que necesita tomar quien usa el componente. Un estado con nombre, un icono intercambiable y una colección variable de campos son decisiones distintas. Convertir las tres en variantes obliga a buscar combinaciones en lugar de expresar el cambio concreto que se necesita. La interfaz del componente debería hacer reconocible esa diferencia.

Figma diferencia variantes, intercambio de instancias y slots según la flexibilidad necesaria. Las variantes representan estados o tipos; un intercambio sustituye una instancia anidada; un slot abre una región para componer contenido. Los slots también son propiedades de componente, por lo que «propiedades frente a slots» no describe dos categorías completamente excluyentes.

Tomemos como ejercicio un diálogo de Configuración del espacio. Su estructura incluye título, cierre, región de contenido y zona de acciones. El contenido podría ser una explicación breve o varios campos de permisos. La estructura debe seguir siendo reconocible en ambos casos. El trabajo consiste en decidir qué controla esa estructura y qué corresponde al contenido insertado.

Escribe dos peticiones antes de modificar la biblioteca: «Mostrar la estructura compacta» y «Añadir otro campo de permisos». El contrato propuesto debería resolverlas con controles diferentes. Cambiar la densidad no debería exigir otro componente de contenido; añadir un campo tampoco debería generar una variante del diálogo para cada cantidad posible de campos.

Asigna cada decisión a un responsable

Asigna responsabilidades antes de poner nombres a las propiedades. En el diálogo propuesto, la estructura controla su padding exterior y la colocación de las acciones. Cada campo anidado controla etiqueta, ayuda y apariencia del input. Quien consume el componente decide qué campos aprobados aparecen en el cuerpo. Así se puede discutir un cambio sin modificar capas ajenas.

La guía de propiedades de Figma describe controles de texto, booleanos e intercambio de instancias. Utiliza texto para un título editable, un booleano para un elemento opcional e intercambio para un recurso sustituible único. Explica cada control por la tarea del consumidor; no expongas cada capa interna simplemente porque la herramienta permita hacerlo.

En el ejemplo, llama Densidad al ajuste de la estructura, Título al encabezado editable y Cuerpo a la región flexible. Evita un ajuste genérico llamado Personalizado. Al elegirlo, nadie sabe si cambia apariencia, contenido o responsabilidad. Quien desarrolla el componente encuentra la misma ambigüedad y puede terminar construyendo una API innecesariamente permisiva y difícil de mantener.

Separa el vocabulario de estado de las recetas de contenido. «Predeterminado» y «compacto» pueden describir la presentación; «permisos» y «explicación» describen el contenido. Fusionarlos en CompactoPermisos multiplica las combinaciones al crecer el producto. La guía de variantes de Figma para estados UI desarrolla la dimensión de estado; documenta después el contenido por separado.

Define un contrato de contenido pequeño

Un slot necesita contrato aunque admita composición libre. Para la región Cuerpo propuesta, describe su finalidad, los elementos recomendados, el orden y el comportamiento vacío. Redacta una frase breve: «Coloca aquí la información y los controles necesarios para esta decisión; conserva la acción principal y la cancelación en la zona de acciones de la estructura».

Los fundamentos de slots de Figma explican cómo mantener contenido flexible dentro de una instancia vinculada. Aprovecha esa capacidad para conservar la responsabilidad compartida sobre la estructura y añade las reglas de tu producto. Poder insertar una capa no demuestra que sea útil, accesible o coherente con la tarea: esas decisiones siguen necesitando revisión del equipo. El ejemplo de grupos de avatares de EmviUI permite separar otras decisiones: cuántos miembros se muestran, qué comunica el indicador adicional y si el control para añadir pertenece a la estructura. La imagen muestra esas partes sin demostrar sus propiedades internas ni su interacción.

Nuestro contrato de aceptación sugerido permite una explicación seguida de dos instancias de campo. También admite un resumen de solo lectura sin campos. Excluye introducir un segundo diálogo independiente dentro de Cuerpo. Son reglas propuestas para entender el ejercicio, no restricciones que Figma deduzca automáticamente a partir del significado de la región o del nombre elegido.

Añade una receta junto al componente: título, finalidad, ejemplos de elementos, acciones y responsable. Incluye un contraejemplo y explica por qué pertenece a otro patrón. Un caso concreto ayuda más que una indicación amplia como «Usa contenido adecuado», porque permite comparar una nueva petición con un límite observable y discutir exactamente dónde deja de encajar.

Construye y prueba una región de contenido

Construye el piloto en una zona controlada de la biblioteca. En el componente principal, selecciona el frame anidado de Cuerpo y utiliza Convert to slot. Inserta después una instancia nueva y compón allí el ejemplo. Figma documenta esta creación y los ajustes del slot. Mantén el piloto separado de las pantallas existentes hasta revisarlo.

Prepara tres casos deliberadamente distintos: una explicación de un párrafo, dos campos etiquetados y un resumen largo de solo lectura. Guarda el contenido exacto en el archivo para reproducir la prueba en futuras revisiones. Un texto corto y atractivo no ejercita el contrato si el producto terminará necesitando traducciones más extensas o un conjunto de controles interactivos.

En cada caso revisa por separado región, estructura y espacio disponible. ¿Crece el contenido como estaba previsto? ¿Se reconocen las acciones? ¿Puede alguien explicar dónde termina el material insertado? Si falla el ancho, consulta la guía de Auto Layout y Fill Container e investiga las reglas de tamaño antes de añadir una variante llamada ContenidoLargo.

Registra los resultados en la tabla propuesta. Son condiciones de aceptación del ejercicio, no una certificación de Figma ni de EmviUI. Para aprobar deben mantenerse el contenido correcto y un límite de responsabilidades comprensible. Si un campo necesita rediseño para encajar, anótalo como incidencia del campo; no alteres silenciosamente la estructura compartida para ocultar el problema.

Revisa límites y valores iniciales

Revisa qué comunica el componente cuando alguien lo inserta por primera vez. El contenido vacío puede señalar trabajo pendiente; una receta inicial útil puede enseñar qué pertenece a la región. El artículo de Figma sobre slots explica la elección intencionada del contenido inicial y su orientación. Elige una opción para el piloto y deja escrita la razón.

Para nuestro diálogo, empieza con una explicación breve y un campo representativo. Identifica el texto claramente como ejemplo para que nadie lo confunda con contenido aprobado del producto. Quien utiliza el componente debe entender la disposición y saber qué sustituir. La muestra enseña un contrato; no inventa una política real sobre cuentas, permisos o funcionamiento de una organización.

No interpretes una sugerencia de cantidad de capas como prueba de que el diseño no puede superar esa estructura. La guía actual de creación de Figma describe los mínimos y máximos como orientación con avisos. Durante la revisión, añade un campo extra deliberadamente y registra el resultado. El equipo todavía debe decidir si esa ampliación encaja con la tarea.

Documenta la diferencia entre sustituir contenido y recuperar el punto de partida. Conserva una muestra antes de probar el restablecimiento. De lo contrario, una revisión podría borrar texto necesario y considerar esa pérdida una limpieza aceptable. El registro debe indicar qué se reemplazó intencionadamente, qué se conservó y por qué la muestra actual sigue representando el trabajo solicitado.

Inspecciona el ejemplo de modal de EmviUI

La imagen real de EmviUI muestra dos disposiciones de modal: una coloca las acciones en paralelo y otra las apila. Ambas incluyen símbolo de estado inicial, título, texto de apoyo y dos acciones. Estas partes visibles ofrecen una referencia concreta para discutir una estructura estable y las regiones que podrían contener contenido variable del producto.

El catálogo de componentes de EmviUI ofrece bloques de diseño en Figma, incluidos modales y botones. Para este ejercicio, utiliza el ejemplo visual para marcar estructura, región Cuerpo propuesta y zona de acciones en tu archivo. La captura no revela propiedades nativas de slot, metadatos de anidación ni la revisión de biblioteca utilizada en un archivo concreto.

No deduzcas comportamiento de aplicación a partir de ninguna disposición. La imagen no demuestra navegación por teclado, gestión del foco ni envío correcto de un formulario. Tampoco afirma que todos los componentes de EmviUI incorporen slots nativos. Inspecciona el componente real al que tienes acceso y diseña después, de forma deliberada, el límite que necesita tu producto.

La guía de arquitectura de bibliotecas de componentes ayuda a decidir si la receta resultante pertenece a la biblioteca compartida o a un patrón específico del producto. EmviUI aporta un punto de partida visual; tu equipo define contrato, contenido permitido y comprobaciones de implementación. Así el recurso resulta útil sin atribuirle pruebas de comportamiento que una imagen no puede aportar.

Relaciona regiones y contrato de implementación

Describe el límite previsto en código con los mismos nombres del diseño. En nuestra implementación propuesta, la estructura del diálogo recibe título, contenido del cuerpo y acciones. La estructura gestiona la interacción exterior; el cuerpo aporta el material de la tarea. Es una API de ejemplo para discutir, no código generado ni una promesa de exportación automática desde Figma.

React documenta el paso de JSX mediante la propiedad children. Es un mecanismo conocido para componer contenido; las propiedades con nombre pueden representar regiones separadas. Elige según el componente real de la aplicación. Explicita la relación conceptual: Cuerpo contiene la tarea y Acciones contiene sus controles de conclusión o cancelación. Compartir nombres no implementa por sí solo el contrato.

Para un modal, el patrón de diálogo de WAI describe contención del foco, Escape y nombre accesible. Comprueba esas conductas en la aplicación con todos los casos de contenido. Añadir campos modifica los elementos interactivos, por lo que superar la prueba de teclado con un párrafo no demuestra que la versión de permisos funcione correctamente.

Define una secuencia de aceptación: abrir el diálogo, identificar su título, recorrer los controles insertados, llegar a las acciones, cerrarlo y verificar el destino previsto del foco. Repítela con contenido largo y presentación compacta. Registra el caso utilizado y cada fallo. Una nota que solo diga «modal accesible» deja demasiada ambigüedad para que otra persona pueda comprobarla.

Publica un límite de composición probado

Publica el piloto como un cambio pequeño, con nombre e inventario de consumidores afectados. La guía de migración de Figma diferencia los recursos provisionales basados en placeholders y variantes. Identifica la estructura de partida antes de elegir el recorrido. Una biblioteca con componentes provisionales anidados necesita otra revisión que un componente nuevo sin consumidores existentes que preservar.

Nuestro registro propuesto incluye estructura anterior, contrato nuevo de Cuerpo, tres casos de prueba y decisión del responsable. Añade al piloto un consumidor con contenido personalizado. Compara el texto necesario y el orden de campos antes y después del cambio. Un ejemplo nuevo puede aprobar mientras otro antiguo todavía necesita una transferencia deliberada de contenido o una excepción documentada.

Trata la retirada o el cambio de nombre del límite de composición como una modificación de biblioteca que debe revisarse. Conserva consumidores representativos antes de cualquier prueba destructiva. La documentación actual de Figma advierte de que eliminar la propiedad slot puede descartar contenido personalizado de instancias. Que la estructura siga pareciendo igual no demuestra que el material interior esté intacto.

Termina con una declaración concreta: «La estructura admite las recetas documentadas de explicación y permisos; el contenido permanece en Cuerpo; las acciones conservan su zona; los casos de aplicación superaron las pruebas de teclado registradas». Enumera aparte lo pendiente. Así diseño y desarrollo tienen un acuerdo verificable y la siguiente petición no amplía silenciosamente la interfaz pública del componente compartido.