Solucionar estilos y variantes EmviUI con React y Tailwind

Para solucionar estilos y variantes EmviUI con React y Tailwind, identifica primero el recurso que has importado. Después separa las capas: compilación, componente renderizado, CSS generado y cascada. Aísla un componente en una ruta mínima y comprueba la corrección sobre una compilación de producción.

La página de botones de EmviUI describe patrones editables de Figma. Una variante de Figma sirve de referencia visual; no establece una API de props de React ni instala CSS. Aquí implementamos una barra ficticia llamada Fieldnote a partir de esa referencia. Las recetas y casos de diagnóstico son propuestas de aplicación, no un SDK oficial de EmviUI.

Localiza la capa del componente que falla

Anota el síntoma exacto antes de cambiar estilos. Si falla la compilación, empieza por el primer error que puedas resolver. Si falta el componente, inspecciona el renderizado. Si existe pero se ve mal, revisa sus reglas. La anatomía del botón permite separar disposición, espacio interior y superficie cuando llegues a la capa CSS.

Crea una ruta temporal de revisión con un botón y su barra contenedora. Conserva las importaciones y la entrada de estilos de la pantalla afectada. Compara el rol problemático con otro que funcione. Registra ruta, versión instalada de Tailwind, apariencia esperada y resultado observado. Cambia una causa cada vez para poder explicar el efecto.

Si la ruta mínima funciona, vuelve a añadir el contexto original por etapas. Así podrás identificar un contenedor que restringe el ancho o una hoja de página que sobrescribe la superficie. No reconstruyas toda la pantalla antes de averiguar qué incorporación hace reaparecer el síntoma. Conserva la reproducción hasta comprobar también la ruta real.

Relaciona las opciones con clases completas

Guarda las opciones finitas del componente en un mapa de cadenas de utilidades completas. La documentación sobre detección de clases explica por qué se pueden perder los nombres construidos por fragmentos durante la ejecución. En este ejemplo, el rol primary selecciona una receta completa de fondo y texto, en vez de aportar una parte del nombre de clase.

Deja que el componente controle su apariencia interna. Quien lo utiliza elige primary o secondary; el componente conserva padding, foco y recetas aprobadas. Si una página necesita separar el botón de otro elemento, pon ese espacio en la barra que lo contiene. Así resulta más sencillo entender las consecuencias de cambiar después el botón compartido.

Define una alternativa para los roles inesperados. Una respuesta de API puede incluir valores ajenos al vocabulario previsto, aunque el código local esté tipado con TypeScript. En este ejemplo, un rol desconocido recibe la receta secundaria. Documenta esta decisión para evitar que una nueva respuesta del servidor se convierta silenciosamente en un estado visual sin revisar.

Evita exponer cualquier nombre de color solo porque acorte el primer ejemplo. Un rol como destructive comunica una intención que se puede revisar; red-600 describe únicamente una elección de pintura. La API propuesta permite cambiar esa pintura sin modificar todas las pantallas. Las comprobaciones de permisos pertenecen al comportamiento de la aplicación y quedan fuera de este mapa de estilos.

const roles = {
  primary: "bg-slate-900 text-white enabled:hover:bg-slate-800",
  secondary: "bg-white text-slate-900 border border-slate-300"
};

export function SaveButton({ role = "primary", disabled = false, children }) {
  const recipe = Object.hasOwn(roles, role) ? roles[role] : roles.secondary;
  return (
    <button type="button" disabled={disabled}
      className={[
        "inline-flex items-center justify-center gap-2 rounded-xl px-4 py-2",
        "font-medium focus-visible:outline-2 focus-visible:outline-offset-2",
        "focus-visible:outline-blue-600 disabled:opacity-50",
        recipe
      ].join(" ")}>
      {children}
    </button>
  );
}

Separa el marcado ausente de los valores dinámicos

Cuando parece faltar una variante, comprueba si React la ha renderizado. La guía de renderizado condicional de React muestra cómo una rama incluye u omite JSX. Revisa el valor de la prop al entrar al componente, la rama elegida y el elemento resultante antes de investigar sus colores.

En Fieldnote, una barra vacía es un fallo distinto de un botón visible con la superficie equivocada. Si falta el elemento, comprueba las ramas de permisos y carga. Si existe, inspecciona la cadena completa de clases y la alternativa de rol. El nombre correcto de una variante en Figma no garantiza la misma escritura ni la misma API en la aplicación.

Separa los valores realmente dinámicos de los nombres de clase. Para un acento de proyecto, utiliza una utilidad estable que lea una propiedad CSS validada, como explica la documentación de estilos propios de Tailwind. El marcador siguiente es decorativo; conserva el título visible. Comprueba ausencia de valor y datos inválidos, además de dos acentos válidos.

<span class="inline-block size-3 rounded-full bg-[var(--project-accent)]"
      style="--project-accent: #2563eb" aria-hidden="true"></span>

Revisa los archivos de origen antes de añadir CSS

Cuando el marcado procede de una dependencia o paquete compartido, verifica que su código está dentro del alcance de detección de la hoja de estilos. En Tailwind v4, una ruta @source explícita permite registrar una biblioteca ignorada. La ruta es relativa a la hoja; incluye el directorio relevante más pequeño. Comprueba la versión al copiar ejemplos de configuración.

Antes de modificar archivos, dibuja un mapa de responsabilidades: la entrada de la aplicación importa la hoja, la hoja detecta el código de interfaz y ese código contiene las cadenas de utilidades previstas. Añade las rutas reales del repositorio junto a estas tres responsabilidades. Una conexión rota ofrece una pista mejor que seguir añadiendo clases de fondo a la página.

Si toda la página aparece sin estilos, revisa primero la importación de la hoja y su respuesta de red. Si falta un rol pero funciona el padding compartido, inspecciona su receta y el archivo que la contiene. Si un paquete funciona en una demostración local y falla al consumirlo, compara las rutas y entradas de compilación de ambos entornos.

Una lista de inclusión pequeña puede servir para un vocabulario intencionado que llega de fuera del código detectado; v4 ofrece @source inline(). Anota el responsable y el motivo de cada excepción. Evita ocultar un contrato defectuoso generando gamas enormes de colores. Para conectar inicialmente la aplicación, consulta la guía de React y Vite.

Inspecciona la regla que gana y su condición

Que exista una utilidad generada no significa que controle el elemento. La documentación de utilidades explica cómo se resuelven las clases que compiten. Inspecciona el estilo calculado del navegador y las condiciones de la regla. Cuando compiten utilidades bajo condiciones equivalentes, importa su orden en la hoja generada. Mover un término al final del atributo class de HTML no constituye una estrategia fiable para sobrescribir el estilo.

Empieza por una propiedad, por ejemplo background-color. Averigua el valor que utiliza el navegador, identifica el selector que lo aporta y comprueba si el selector esperado falta, aparece tachado o está condicionado. Solo entonces modifica el código. Una regla ausente, una regla que pierde y una media query inactiva son fallos diferentes.

Las variantes enabled:hover: y focus-visible: describen condiciones; no crean el comportamiento de la aplicación. La documentación de estados de Tailwind explica los selectores de estas variantes. En el botón de ejemplo, disabled es un atributo HTML real. Añadir disabled:opacity-50 sin activar ese atributo no deshabilitaría por sí solo el control.

En estilos dependientes del ancho, las utilidades sin prefijo forman la base y las variantes de breakpoint se aplican desde su umbral hacia arriba, según la documentación de diseño adaptable. Revisa la barra justo antes y después de la transición elegida. Lee los breakpoints del proyecto, sin dar por válidos los números de otro repositorio. Para revisar texto largo, continúa con la lista de comprobación de formularios y estados.

Revisa los estados del botón con EmviUI

La página de botones de EmviUI ofrece patrones editables de Figma para comparar tratamientos de acciones. La muestra real que aparece debajo incluye opciones rellenas, delineadas y ligeras en varios colores. Úsala para escoger un vocabulario visual reducido y anotar qué estados debe demostrar la implementación de la barra.

En este ejercicio, elige un tratamiento principal y otro secundario. Coloca la misma etiqueta «Guardar proyecto» en ambos dentro de Figma y compara su jerarquía junto al título del proyecto. Anota las apariencias previstas para reposo, hover y acción no disponible en tu hoja de revisión. La imagen aporta ejemplos visuales, pero no prueba los atributos HTML ni las reglas que los implementan.

En el navegador, añade un indicador de foco visible y llega a la acción con Tab. La explicación de WCAG sobre foco visible describe por qué quien usa teclado necesita identificar el control enfocado. Haz esta revisión por separado de la prueba con ratón. Oscurecer el fondo al pasar el puntero no muestra a una persona con teclado dónde está.

Utiliza disabled cuando la acción esté realmente indisponible y explica el motivo junto al control si el contexto no lo aclara. En Fieldnote, «No hay cambios que guardar» informa más que un botón atenuado sin explicación. Si falla el guardado, conserva el nombre editado y permite reintentar. La receta visual no puede decidir si el servidor llegó a guardar.

EmviUI ayuda a acordar la apariencia que se va a revisar. La aplicación sigue necesitando sus propios eventos, validación y pruebas de navegador. Mantén una relación breve entre cada tratamiento seleccionado en Figma, el rol del componente y el estado observado. Para completar la revisión de interacción, consulta los ejemplos de diálogos con Tailwind CSS.

Resuelve errores de compilación antes del acabado visual

Una compilación fallida abre otra rama del diagnóstico. Lee el primer error accionable con su archivo, línea y comando. Comprueba si existe la importación, si su exportación coincide con el uso y si el comando se ejecuta desde el paquete previsto. Resuelve ese error antes de modificar los colores del botón.

En una aplicación Vite, la documentación de compilación de producción explica la entrada y la ruta pública base. Ejecuta el script existente del proyecto y sirve su salida mediante la previsualización configurada. Si compila pero la hoja desplegada devuelve 404, inspecciona la URL emitida y la ruta de alojamiento. Es un problema de entrega, no una prueba de que falte una receta.

Conserva el comando exacto que falla en el registro de la incidencia. Un módulo ausente exige corregir una importación o dependencia; una declaración CSS mal formada requiere arreglar la sintaxis. Generar más utilidades no repara esos errores. Cuando compile, vuelve a la ruta original y repite las pruebas de clases y estados: resolver un fallo no verifica todas las decisiones visuales.

Verifica la página compilada con una matriz de pruebas

Termina con la compilación real de producción servida mediante el comando de previsualización del proyecto. Abre directamente la página, recárgala y repite los cambios de estado importantes. Registra el resultado frente al contrato utilizado durante la revisión de diseño. La matriz siguiente es una herramienta propuesta; cada aplicación debe ajustar los casos a sus propias acciones.

Carga primero los roles principal y secundario sin pasar antes por otra página. Confirma que ambos conservan superficie y espacio interior. Introduce después un rol desconocido y verifica la alternativa documentada. Este paso evita un hueco frecuente en las demostraciones: haber revisado únicamente la combinación que siempre sale bien y no las opciones que utilizará otra pantalla.

Llega con teclado a Guardar, deshabilítalo mediante el estado real de la aplicación y vuelve a habilitarlo al editar. Observa el indicador de foco y la disponibilidad de la acción. Reduce después el ancho y utiliza la etiqueta española más larga. Que la compilación termine correctamente no garantiza una interfaz legible ni una acción que se pueda utilizar.

Conserva pruebas breves: identificador de compilación, ruta, rol probado, regla observada y resultado. Si vuelve el fallo, ese registro orientará a la siguiente persona. Puedes dar la lista de clases por terminada cuando sus responsabilidades visuales, archivos de origen y condiciones de estado se puedan explicar desde la página que realmente está funcionando.