Responsive “de verdad” y diseño por componentes

Responsive no es “hacer que quepa”

El diseño responsive no consiste en encoger cosas hasta que entren. Consiste en reorganizar decisiones cuando cambian las condiciones.

Una interfaz responsive responde a:

• Ancho disponible
• Densidad de información
• Prioridad de contenido
• Forma de interacción

El error común es pensar en tamaños de pantalla. El criterio real es pensar en espacio útil y carga cognitiva.

Tailwind no “hace responsive” por sí mismo. Obliga a declarar cuándo y cómo cambia una decisión.

Mobile-first como disciplina, no como lema

En Tailwind, las clases base representan el estado móvil.

Los breakpoints no añaden estilos: los sustituyen progresivamente.

Modelo mental correcto:

• Base: mínimo viable
• sm: mejora cuando hay algo más de espacio
• md: reorganización
• lg+: expansión controlada

Mobile-first no es diseñar para móvil. Es diseñar sin suposiciones.

Error habitual:

• Pensar el diseño en desktop y luego “parchear” móvil.
• Usar demasiados breakpoints sin una razón clara.

Breakpoints como cambio de estructura

Un breakpoint bien usado cambia la estructura, no solo el tamaño.

Ejemplos de cambios estructurales:

• De columna única a dos columnas.
• De menú oculto a navegación visible.
• De lista vertical a grid.

Ejemplos de cambios pobres:

• Solo aumentar padding.
• Solo subir font-size.
• Duplicar clases sin modificar jerarquía.

Si en un breakpoint no cambia ninguna relación entre elementos, probablemente no hacía falta.

Composición responsive con Grid y Flex

Responsive no se resuelve con una sola herramienta.

Criterio base:

• Grid define regiones que aparecen o desaparecen.
• Flex organiza contenido dentro de una región.

Un patrón común:

• Mobile: una sola columna, todo en flujo.
• Desktop: grid con regiones claras (sidebar, main, meta).

Error frecuente:

• Usar Flex para todo y “empujar” elementos con márgenes.
• Grid rígido desde el inicio que no escala bien hacia abajo.

Orden visual vs orden en el DOM

Responsive real distingue entre:

• Orden lógico (DOM)
• Orden visual (layout)

Tailwind permite cambiar orden visual sin romper accesibilidad, pero debe hacerse con criterio.

Regla general:

• El orden en el DOM debe seguir la lectura natural.
• El layout puede reorganarse visualmente si no rompe esa lectura.

El DOM es para humanos y máquinas.

El layout es solo para humanos.

Errores habituales:

• Reordenar contenido crítico solo por estética.
• Romper el flujo de lectura en móvil.

Componentes como unidades responsivas

Un componente no es un bloque fijo. Es una unidad que se adapta.

Un buen componente:

• Funciona en columna y en grid.
• Tolera cambios de ancho.
• No depende de un contexto único.

Señal de componente mal diseñado:

• “Este componente solo funciona aquí”.
• Necesita excepciones constantes en responsive.
• Rompe cuando cambia el layout padre.

Si un componente no sobrevive a un cambio de ancho, no es un componente: es un fragmento.

Variantes responsive y precedencia

En Tailwind, el orden importa:

• Base → sm: → md: → lg: → xl:

Las variantes no se suman, se pisan.

Problema típico:

• Clases que “no funcionan”.
• Estilos que parecen aleatorios.

Causa real:

• Confusión sobre qué variante está activa.
• Falta de un estado base claro.

Patrones responsive comunes (bien resueltos)

Patrones que funcionan:

• Cards que pasan de stack a grid.
• Headers que simplifican contenido en móvil.
• Sidebars que desaparecen o se convierten en secciones.

Patrones problemáticos:

• Menús con demasiadas opciones en móvil.
• Grids con demasiadas columnas pequeñas.
• Componentes que dependen de hover en pantallas táctiles.

Errores frecuentes al empezar con responsive

• “En desktop se ve bien”: criterio insuficiente.
• “En móvil está todo”: pero sin jerarquía.
• “Uso muchos breakpoints”: sin cambios reales.
• “El layout se rompe”: dependencia excesiva del ancho fijo.

Este módulo introduce el tercer pilar del sistema: una interfaz no solo debe estar bien diseñada, debe adaptarse sin perder sentido.