Saltar al contenido

Patrones

Beta

Cómo se combinan los componentes para resolver las situaciones que se repiten en todo producto.

Un componente resuelve una pieza; un patrón resuelve una situación. Estos son los que aparecen en casi cualquier pantalla de FDS. Cada uno está armado con los componentes reales del sistema: copiá el código como punto de partida.

Formulario

Te enviamos ahí la confirmación.

Jornada
  • Una columna. Los campos en una sola columna se completan más rápido y funcionan igual en mobile. Dos columnas solo para pares cortos (ciudad / CP).
  • Label arriba, siempre visible. El placeholder es un ejemplo, no el nombre del campo.
  • Marcá lo opcional, no lo obligatorio, cuando la mayoría es obligatoria.
  • Validá al salir del campo o al enviar, nunca mientras se escribe. El error va junto al campo y dice cómo arreglarlo.
  • El botón principal dice qué pasa: "Inscribirme", no "Enviar". Cancelar va a la izquierda, en text.
  • Al enviar, loading en el botón; al terminar, un Toast o la pantalla siguiente.
  • Campos: autoComplete e inputMode correctos activan el teclado y el autocompletado adecuados.

Cargando, con datos, vacío

Toda lista o panel tiene tres estados, y hay que diseñar los tres.

EstadoComponenteRegla
CargandoSkeleton con la forma del contenidoAparece después de ~300 ms; si pasa de ~10 s, mensaje.
Con datosEl contenido—
VacíoEmpty stateDice por qué no hay nada y qué hacer. Distinto para "primera vez", "sin resultados" y "error".

El contenedor no cambia de tamaño entre estados: el skeleton reserva el lugar.

Acción destructiva

Confirmar, ejecutar y dejar deshacer.

  1. Modal de confirmación sm, icono de alerta, título con la pregunta completa y el nombre de la cosa ("¿Dar de baja Cálculo I?"). El subtítulo dice la consecuencia.
  2. Footer full: Cancelar primero (recibe el foco), la acción con verbo + objeto. Sin ✕: hay un Cancelar visible.
  3. Al ejecutar, un Toast con Deshacer y un timeout largo (10 s). Si no se puede deshacer, decilo en el modal.

Estructura de app

Navbar arriba con marca y acciones; Sidebar a la izquierda con la navegación; el contenido ocupa el resto y es lo único que hace scroll.

Inicio

Hola Julia. Tenés 2 finales esta semana y una inscripción abierta.

Cálculo II · Final jueves 9:00
Física I · Final viernes 14:00
  • La navegación vive en un solo lugar. El Navbar no repite los destinos del Sidebar: queda con marca, búsqueda, notificaciones y cuenta.
  • Angosto, la misma lista en un Drawer. Los SidebarItem van adentro de NavbarMobile tal cual; el Sidebar se esconde con @max-[640px]:hidden sobre un contenedor @container.
  • Plegable, y recordá la preferencia con onCollapsedChange (cookie o localStorage) para que no vuelva a abrirse en cada carga.
  • El <main> lleva min-w-0 y overflow-y-auto: así una tabla ancha no empuja el sidebar.
  • Breadcrumb y título de página van adentro del <main>, no en el Navbar.

Feedback: cuál usar

Quiero…Usá
Confirmar que algo que hice salió bienToast
Avisar de un estado que sigue ahí (vence, falta, falló)Alert junto a lo afectado
Anunciar algo a todo el sitioBanner arriba de todo
Marcar un campo mal completadoerror del Input
Pedir una decisión antes de seguirModal
Indicar el estado de un registroChip status
  • Secciones hermanas de una misma cosa → Tabs.
  • Dónde estoy en un sitio profundo → Breadcrumb.
  • Pasos de un proceso → Stepper arriba del formulario.
  • Listas largas → Pagination; feeds → "Cargar más".
  • Acciones sobre un ítem → Dropdown menu en un "…".
  • Detalle sin salir de la lista → Drawer.

Jerarquía de acciones en una pantalla

  • Un solo botón Fill por zona: la acción que la persona vino a hacer.
  • Secundarias en stroke o tonal; terciarias y "Cancelar" en text.
  • Acciones de utilidad (exportar, filtrar) en stroke con icono, o en un menú.
  • La acción principal va a la derecha en desktop y arriba (primera) en mobile cuando se apilan.