Componentes configurables o separados para tablas y formularios

Usa un componente configurable cuando sus opciones mantengan la misma interacción, semántica y responsabilidad sobre el estado. Separa los componentes públicos cuando cambie la tarea o el contrato de comportamiento, y comparte los controles pequeños por debajo. Una tabla compacta y otra espaciosa pueden tener la misma API; un informe y un editor de celdas suelen necesitar contratos distintos. El objetivo es que cada consumidor resulte predecible.

Esta guía propone un criterio práctico para decidir entre componentes configurables y componentes separados en tablas adaptables y formularios complejos con muchas variantes. El marco y los casos ficticios son recomendaciones de diseño apoyadas en la documentación enlazada. No representan una taxonomía obligatoria ni una mejora de productividad medida.

Decide el límite según el comportamiento

Empieza describiendo la promesa del componente en una frase. Para una lista de clientes: «Comparar clientes, abrir su ficha y seleccionar registros para una acción opcional». Para un editor de asignaciones: «Recorrer celdas, modificar valores y confirmar o cancelar cambios». Que ambos tengan filas y bordes no hace equivalentes esas promesas.

Anota qué debe permanecer estable: rol accesible, comportamiento de teclado, formato de datos, responsable de los cambios y recuperación ante fallos. Clasifica después las opciones propuestas. La densidad, un título visible o un renderizador de celda pueden personalizar una misma promesa. Una opción que sustituye navegación por edición puede cambiar esa promesa y justificar una entrada pública independiente.

Por ejemplo, es razonable exponer CustomerTable y AllocationGrid en lugar de una EverythingTable cuyas opciones editable, selectable, spreadsheet y mobile redefinen la interacción de manera implícita. Es una recomendación para la API pública, no una petición de duplicar todo el código. Ambas entradas pueden compartir formatos, badges de estado, textos de ausencia de resultados y estilos de superficie.

Mantén las decisiones cerca de su consumidor. Si una pantalla necesita descargar datos, prueba primero a componer un botón junto a la tabla antes de añadir permisos, endpoint y formato de exportación a todas las instancias. Para ubicar esa decisión dentro de una biblioteca, consulta la guía de arquitectura de componentes y patrones.

Distingue opciones válidas y estados imposibles

Cuenta combinaciones con sentido, no solo propiedades. Tres booleanos independientes permiten ocho configuraciones teóricas, aunque el producto quizá admita solo cuatro. Registra cuáles son válidas y qué debe hacer quien consume el componente cuando solicita una combinación no admitida. La dificultad aumenta cuando la API obliga a memorizar exclusiones que no aparecen en el contrato.

Imagina un formulario de facturas con isSaving, hasError e isComplete. Estar guardando y completado a la vez puede no tener sentido en ese flujo. Sustituye esas banderas de estado por editing, submitting, failed o saved y conserva aparte los datos que sí sean independientes. La guía de React sobre estructura del estado recomienda evitar contradicciones y datos redundantes; no establece un límite numérico de props.

Documenta una tabla breve de capacidades: modo admitido, entradas necesarias, acciones disponibles, responsable del estado y ejemplo de comprobación. El modo de selección puede requerir selectedIds y onSelectionChange. Un modo de lectura no debería exigir funciones que nunca utiliza. Si el lenguaje lo permite, representa los modos excluyentes de forma explícita en vez de aceptar un conjunto desordenado de campos opcionales.

No dividas automáticamente al llegar a cinco props o diez variantes. Un campo de fecha puede necesitar varias opciones independientes y legítimas. A la inversa, dos propiedades pueden ocultar comportamientos incompatibles. Pide a otra persona que configure los dos consumidores más diferentes sin leer los condicionales internos. Si no puede anticipar qué entradas importan, aclara el contrato antes de sumar otra bandera.

Define contratos distintos para tabla y grid

Una tabla con enlaces o botones no se convierte automáticamente en un grid ARIA. La decisión depende del modelo de interacción previsto. Trata los cambios de semántica y teclado como decisiones de arquitectura, acompañadas de ejemplos y criterios de aceptación concretos.

El patrón de tabla de WAI describe una estructura tabular cuyos controles mantienen sus paradas de tabulación y recomienda HTML nativo cuando sea posible. El patrón de grid de WAI define un widget compuesto con gestión del foco y navegación direccional. Añadir un rol no implementa esa navegación. Una tabla nativa puede contener controles interactivos sin adoptar el comportamiento de grid.

En una tabla de clientes orientada a consulta, especifica título, cabeceras, anuncio de ordenación y acciones de fila. En un editor de presupuestos, define por separado cómo entrar en una celda, editar, salir de edición y comunicar un guardado fallido. Decide después qué renderizadores pequeños pueden compartir. Mantén las reglas de selección y movimiento del foco junto al contrato que las utiliza.

Durante la revisión, usa los mismos datos pequeños en ambos contratos: un nombre largo, un valor opcional ausente y una acción no disponible. Comprueba que la persona destinataria pueda alcanzar y comprender cada acción. Conserva los resultados junto a los ejemplos del componente. La guía de tablas adaptables en móvil desarrolla la decisión específica sobre presentar columnas en pantallas pequeñas.

Revisa celdas reutilizables con EmviUI

Utiliza un espécimen visual real para identificar piezas reutilizables antes de generalizar una pantalla entera. La colección de celdas de EmviUI muestra texto, avatares, badges, progreso y acciones. Son candidatos concretos para contenido de celda independiente, sin convertir cada combinación en una variante de tabla gigante.

El catálogo actual de componentes de EmviUI sirve como punto de partida visual para el ejercicio. Compara los controles Edit y Delete con etiqueta y el grupo que utiliza solo iconos. Anota los nombres que deberá exponer tu implementación, la acción asociada y quién la autoriza. La imagen acredita apariencia; no demuestra soporte de teclado, permisos del backend ni comportamiento en producción.

Compón una lista ficticia con una celda de cliente, otra de estado y otra de acciones. Reutiliza el estado en un panel de detalle sin importar la tabla completa. Si necesita contexto exclusivo de tabla, decide si esa dependencia es necesaria o si la celda ha absorbido responsabilidades del padre. EmviUI facilita explorar la composición visual; los contratos de datos y la verificación de comportamiento corresponden a tu aplicación.

No deduzcas precios a partir de importes de ejemplo visibles en el espécimen. Trátalos como contenido ilustrativo. Aquí interesa saber si cada parte comunica su función y puede pasar a otro contexto. Mantén la referencia original junto a la propuesta de API para que diseño y desarrollo discutan los mismos elementos concretos, sin asumir capacidades que una imagen no puede confirmar.

Compón formularios según tareas reales

En formularios complejos, comparte grupos estables de campos y deja que cada tarea controle su envío. Crear un cliente y editarlo pueden compartir datos de contacto, pero tener valores iniciales, permisos, cancelación y finalización diferentes. Un formulario único con interruptores isCreate, isEdit e isWizard puede esconder esas diferencias.

La composición ofrece otra salida: coloca ContactFields dentro de formularios específicos y recibe acciones o contenido de ayuda mediante children o regiones con nombre. React documenta cómo pasar JSX mediante children para que un contenedor aloje contenido sin conocer su implementación. Aplica esa flexibilidad cuando conserve un límite comprensible; permitir cualquier anidamiento no crea por sí solo una buena API.

Conserva la agrupación semántica al componer. El tutorial de agrupación de WAI explica fieldset y legend para controles relacionados. Su tutorial de validación distingue la respuesta en cliente de la validación en servidor. En esta propuesta, el grupo presenta etiquetas, ayuda y mensajes asociados, mientras el formulario de tarea interpreta la respuesta del servidor y decide el siguiente paso.

Como caso concreto, haz que el servidor rechace el identificador del cliente aunque el correo tenga formato válido. Conserva el correo escrito, muestra el problema junto al identificador y define cómo debe mapear la respuesta quien consume el formulario. Un campo de texto compartido no debería conocer reglas comerciales de cuentas. Documenta si editar un valor elimina su error anterior y compruébalo con el equipo de producto.

Asigna un responsable claro al estado

La responsabilidad sobre el estado forma parte de la API. Si una tabla y un panel de detalle deben mostrar el mismo cliente seleccionado, elige un único responsable para su identificador. Ambos consumidores reciben el valor actual y solicitan cambios mediante un evento explícito. Separa el estado local de presentación del estado compartido del producto.

La documentación de React sobre estado compartido explica cómo trasladar estado coordinado a un padre común. Aplícalo deliberadamente: el foco temporal de un campo puede ser local; el cliente activo debe estar por encima de las dos vistas. Define qué ocurre si el cliente desaparece de los resultados y si aplicar un filtro conserva la selección.

Para el envío, dibuja las transiciones admitidas: edición a envío; envío a guardado o fallo; fallo a envío tras corregir. Es un modelo ilustrativo, no la especificación completa de todos los formularios. Añade cancelación o éxito parcial cuando la tarea lo requiera. Conserva errores del servidor y valores introducidos junto al estado, con responsabilidades claras.

Diseño debería poder asociar cada estado con un ejemplo, y desarrollo identificar el evento que lo activa. Para preparar las alternativas visuales en Figma, sirve la guía de variantes y estados de interfaz. Una variante representa un estado visual; no implementa las transiciones de ejecución ni la persistencia. Esa diferencia permite revisar ambas partes con criterios adecuados.

Adapta el layout sin perder el trabajo

Los cambios adaptables pueden revelar límites mal definidos. Convertir un informe ancho en una lista estrecha puede cambiar solo la disposición o eliminar tareas esenciales de comparación y edición. Determina cuál es tu caso antes de crear APIs de escritorio y móvil que evolucionen por separado.

La explicación de Reflow de WAI aborda una anchura equivalente a 320 píxeles CSS y excepciones para contenido que necesita dos dimensiones. La excepción de una tabla no permite desbordar los controles ajenos a ella. Especifica qué región necesita desplazamiento horizontal y qué elementos de la página deben adaptarse sin él.

En el formulario ficticio, escribe un valor, provoca un error y cambia el ancho de ventana. Los datos pendientes deben seguir la regla de conservación acordada para el producto. React explica la conservación y el reinicio del estado según identidad y posición en el árbol: sustituir un subárbol o cambiar su key puede reiniciar su estado local. Un breakpoint no debería descartar trabajo accidentalmente.

Prefiere un único responsable del borrador y dos presentaciones solo cuando sean necesarias. Mantén identificadores estables de campos y verifica el foco si un control se desplaza o desaparece. Al convertir tablas en tarjetas, conserva etiquetas y acciones esenciales de forma explícita. Un cambio visual no garantiza que se entiendan las mismas relaciones. Comprueba la implementación real, porque el lienzo estático no acredita estas propiedades.

Migra un consumidor antes de ampliar

Migra el consumidor más pequeño que permita comprobar el comportamiento discutido. Mantén sus datos, permisos y acciones esperadas mientras cambias el límite del componente. Así puedes comparar los contratos anterior y propuesto sin introducir simultáneamente un flujo de producto nuevo que dificulte interpretar el resultado.

Por ejemplo, extrae CustomerActions de la tabla, expón selectedIds con un único responsable documentado y traslada la petición de alta a CreateCustomerForm. Conserva las etiquetas visibles durante ese cambio. Revisa después si un segundo consumidor reutiliza las piezas sin importar comportamiento ajeno. Si no puede, vuelve a examinar la abstracción mientras el alcance siga siendo pequeño.

1. Escribe el comportamiento estable y las configuraciones admitidas.
2. Separa los contratos de semántica o teclado que sean diferentes.
3. Compón campos, celdas y acciones alrededor de responsables por tarea.
4. Comprueba fallos, datos vacíos, permisos y pantallas estrechas.
5. Documenta la migración y retira la ruta antigua de forma deliberada.

La evidencia útil es un consumidor que funciona, ejemplos representativos y un contrato de estado explícito. Si dos componentes públicos necesitan corregir el mismo badge compartido, modifícalo una vez. Si diverge su proceso de guardado, mantén ambos flujos comprensibles. Reutilizar debe facilitar razonar sobre los cambios; la cantidad de nombres de componentes exportados no es una medida suficiente de éxito.