Modos de variables de Figma no funcionan: vínculos y herencia

Si los modos de variables de Figma no funcionan, revisa la propiedad que no cambia, confirma su vínculo con una variable y sigue el modo efectivo por las capas superiores. Después compara el valor del contexto elegido con el resultado esperado. Ver una etiqueta de modo ayuda, pero no demuestra que todas las partes visibles consuman la variable correcta.

Esta guía diagnostica una tarjeta de ajustes cuyo fondo responde al cambio, mientras el botón y el espaciado permanecen iguales. La tarjeta, los nombres y las pruebas son ejemplos editoriales. Trabaja en una copia o en una muestra pequeña para aislar la causa. Buscamos una reparación que puedas justificar con una propiedad, una colección, un valor y un resultado reproducible.

Registra la propiedad que falla

Empieza con una observación concreta: «El fondo de la tarjeta cambia de tema, pero el relleno del botón Guardar sigue igual». Anota la capa y la propiedad exactas, la colección, el modo esperado y el resultado visible. Evita resumirlo todo como «el tema está roto».

Prepara una ficha breve antes de editar. Incluye el enlace al frame afectado, una captura del panel de la propiedad, el aspecto esperado y el lugar donde ocurre: biblioteca de origen, archivo consumidor o reproducción del prototipo. Pide identificar la última acción que modificó el resultado. Es una propuesta de registro para el diagnóstico, no una plantilla obligatoria de Figma.

Para nuestra tarjeta, crea tres filas: relleno del fondo, relleno del botón y padding horizontal. Escribe una expectativa independiente en cada una. Que cambie el color no implica que también deba cambiar el espaciado. El tema visual y la densidad pueden responder a decisiones distintas del producto; primero aclara lo que el equipo quiere conseguir.

Añade un rectángulo nuevo junto a la tarjeta como muestra de control. La prueba resulta útil cuando puedes decir qué propiedad falla y en qué contexto. Conserva la instancia original y modifica una cosa cada vez. Si nadie puede repetir el resultado, todavía falta evidencia para considerar estable la reparación de la biblioteca.

Comprueba el vínculo antes del modo

Inspecciona el campo real de relleno, trazo, texto o valor numérico. La documentación de aplicación de variables detalla las propiedades compatibles y advierte que arrastrar los controles de padding o gap sobre el lienzo puede separar los vínculos numéricos. Comprueba el campo; un valor conocido no demuestra una conexión.

En el experimento propuesto, vincula el rectángulo de control a la misma variable de superficie que usa la tarjeta. Cambia la colección prevista entre los dos contextos de prueba. Si el rectángulo responde y el botón no, centra la investigación en la propiedad y los antecesores del botón. Si ninguno responde, revisa primero la variable compartida y la selección del modo.

Para una inspección con desarrollo, Figma documenta los vínculos de variables y los tipos compatibles. El vínculo de un nodo contiene una referencia a la variable; coincidir con su valor literal actual no aporta la misma evidencia. Solicita el vínculo de la propiedad relevante, sin volcar todo el archivo. Este paso es opcional: el diagnóstico visual puede empezar en el panel.

Si interviene un estilo reutilizable, revisa la propiedad dentro de ese tratamiento. La guía sobre variables y estilos en Figma explica esa relación. Repara la conexión en el nivel adecuado y prueba otro consumidor antes de ampliar el cambio. Sustituir un tratamiento compartido para arreglar una única captura puede generar trabajo en otras pantallas.

Sigue el modo efectivo por las capas

Sigue la capa seleccionada hacia arriba por sus padres reales. La guía de modos de Figma explica la herencia con Auto y el uso del modo predeterminado cuando ningún antecesor establece otro. Un hijo con un modo deliberado requiere atención propia; la agrupación visual no identifica por sí sola al contenedor relevante.

Dibuja el recorrido de nuestro ejemplo: página, frame de ajustes, instancia de tarjeta, botón y capa del relleno. Junto a cada elemento registra la colección relevante y si su modo es heredado o explícito. Empieza con una sola propiedad que falle. Dibujar toda la biblioteca en el primer paso dificulta revisar el diagnóstico.

La referencia resolvedVariableModes de la API de plugins distingue los modos establecidos en un nodo de los modos efectivos por colección, que incluyen ajustes de sus antecesores. Desarrollo puede comparar esos registros si el panel deja dudas. La pregunta útil es qué modo llega a esta capa para esta colección, no cuántas etiquetas aparecen en el documento.

En la muestra, prueba una excepción intencional junto a un elemento que herede. Anota si la excepción responde a una necesidad, como una zona promocional con contraste propio, o a un ajuste accidental. Recupera la herencia donde el diseño lo requiera. Una excepción aparentemente extraña puede ser correcta al revisar la interfaz completa y la función que cumple.

Revisa valores y alias por separado

Abre la variable exacta y compara los valores de los dos contextos. La guía de gestión de variables documenta los alias entre variables del mismo tipo y sus ámbitos de aplicación. El alias es una referencia que conviene seguir; el ámbito determina en qué propiedades se ofrece la variable.

Escribe una tabla pequeña con los valores esperados para la tarjeta. Por ejemplo, surface/default podría apuntar a un neutro claro en un contexto y a otro más profundo en el segundo, mientras space/card permanece en 24. Son decisiones ilustrativas, no valores universales recomendados. Un padding que no cambia es correcto si ambas definiciones coinciden de forma deliberada.

Sigue una cadena de alias cada vez y registra la colección de cada paso. Los nombres parecidos justifican una revisión; no prueban que dos referencias sean intercambiables. Compara el valor final con la ficha del caso antes de modificar una primitiva de la que quizá dependan muchas pantallas.

Si la diferencia visual es demasiado sutil, utiliza una variable temporal de diagnóstico en la copia, identificada con claridad. Elige valores de prueba distinguibles, comprueba la conexión y elimina la sustitución al terminar. Esa prueba verifica el recorrido ejercitado, no todo el sistema de diseño. Repite después la comprobación con el valor que realmente debería utilizar el producto antes de aceptar el arreglo.

Comprueba el límite de la biblioteca

Compara la misma propiedad en la biblioteca de origen y en un archivo consumidor. La documentación de publicación de bibliotecas indica que los cambios del origen deben publicarse para que los consumidores puedan revisar y aceptar las actualizaciones. Una muestra correcta en origen no confirma que otro archivo tenga la misma revisión.

Anota el archivo fuente, el cambio que debería haberse publicado y el consumidor utilizado para comprobarlo. Busca una colisión de nombres o un recurso local antiguo antes de atribuir el fallo a los modos. En nuestra ficha propuesta hay dos casillas independientes: «funciona en origen» y «funciona en el consumidor». Ninguna debería completarse de memoria.

Revisa la actualización con la persona responsable. Describe el cambio previsto, por ejemplo recuperar el vínculo del relleno del botón, e identifica una pantalla que deba conservar su aspecto. Acepta la actualización relevante en un consumidor de prueba y repite el caso inicial. Evita mezclar una limpieza general con una investigación que todavía necesita aislar su causa.

Cuando el consumidor pase, distingue lo reparado de lo que simplemente has inspeccionado. Si aparecen problemas frecuentes de publicación, consulta el flujo de versiones y pipeline de tokens para acordar responsabilidades. La reparación actual debería ser suficientemente pequeña para que otra persona evalúe su impacto sin reconstruir todas las decisiones de la biblioteca.

Separa acciones del prototipo y configuración

Si el diseño funciona en el lienzo y falla al reproducirlo, inspecciona la interacción por separado. Figma documenta Set variable mode en prototipos como una acción sobre la página; los objetos con modo explícito conservan su contexto. Confirma la colección y el modo de la acción antes de reconstruir el interruptor.

Prepara un flujo mínimo con un disparador y un resultado observable. Inicia cada prueba desde el mismo punto, ejecuta la misma acción y anota cómo quedan el fondo y el botón. Que se mueva el indicador del interruptor no basta: también deben responder las propiedades que forman la experiencia prevista.

Mantén un componente con contexto fijo dentro del experimento si el producto lo necesita. Márcalo como excepción en las notas para evitar que otra persona lo «repare» después. Contrasta el resultado con la ficha y repite la prueba en la pantalla real. Así, una interacción sencilla que funciona no oculta el fallo de un consumidor anidado.

Si la acción debería seleccionar un estado del componente, revisa el modelo de variantes y estados como una cuestión separada. Especifica si se pretende cambiar el contexto de valores o elegir una configuración del componente. Aclarar la intención facilita tanto las pruebas como la explicación de la reparación en el handoff.

Crea una muestra pequeña de regresión

Elige pocos controles cuyo aspecto permita detectar regresiones. El catálogo de componentes de EmviUI incluye foundations y botones que sirven como referencias visuales. La muestra inferior permite separar las comprobaciones del relleno, la etiqueta y el icono; no demuestra sus vínculos internos con variables.

Selecciona una acción principal, otra sutil y una referencia con apariencia deshabilitada de tu diseño de trabajo. Para cada una registra el resultado esperado de superficie, texto e icono en ambos contextos. Separa los cambios de estado de los de tema. Los tratamientos visibles de la captura no prueban hover, compatibilidad con modos ni conformidad de accesibilidad.

EmviUI ayuda a partir de una anatomía reconocible mientras construyes esta prueba. Inspecciona el archivo que realmente utilices y conecta las propiedades previstas a las decisiones aprobadas por tu equipo. No presupongas que un recurso descargado ya coincide con los nombres de tus colecciones o tu proceso de versiones. La muestra de aceptación aporta la evidencia de esa integración.

Termina con tres comprobaciones: un control nuevo, la instancia reparada y otro consumidor real. Registra las diferencias deliberadas. Si solo pasa la primera, la investigación sigue abierta. Si pasan todas, conserva un frame pequeño y una explicación del fallo para reconocer en el futuro la misma excepción o un vínculo que se haya separado.

Entrega una reparación reproducible

Entrega una explicación breve que permita reproducir el fallo y su reparación. Incluye el recorrido de capas, la propiedad, la identidad de la variable, el modo de la colección, la revisión de origen y el resultado anterior y posterior. Enlaza la muestra e identifica el consumidor comprobado. Una captura aislada pierde buena parte del contexto.

Separa los hechos comprobados de las observaciones pendientes. Si el control responde y una instancia antigua sigue siendo inconsistente, consérvala y describe la diferencia sin atribuir automáticamente un bug a la plataforma. Si el origen y el consumidor discrepan tras actualizar, facilita los pasos exactos y la revisión observada a la persona responsable.

En nuestra tarjeta, el éxito exige que fondo, acción y espaciado cumplan su expectativa, que la excepción siga siendo deliberada y que la pantalla consumidora supere la misma prueba. Guarda la nota con el cambio de biblioteca. La siguiente persona debería poder explicar por qué el resultado es correcto sin repetir toda la investigación.

Acuerda un punto de recuperación antes de compartir la actualización. Conserva la muestra aprobada anterior y describe qué cambio revertirías si falla otro consumidor. Pide a una persona del equipo que repita los pasos escritos sin indicaciones adicionales. Sus observaciones pueden revelar una suposición oculta, como seleccionar otro frame o utilizar una biblioteca antigua. Añade ese detalle a la nota antes de dar el caso por cerrado.