Kit de chat para React: borradores, reintentos y accesibilidad

Un kit de chat para React resulta útil cuando permite crear una conversación que conserva borradores, explica fallos de envío y sigue siendo legible al recibir mensajes. Empieza por un caso completo de envío y reintento y adapta después las piezas visuales. Comprueba juntos historial, editor, información de entrega y vista móvil antes de ampliar la bandeja. Esta guía utiliza una conversación de soporte como ejercicio concreto de implementación y aceptación.

Empieza por una conversación de prueba

Construye una pequeña conversación de soporte antes de adaptar una bandeja completa. Incluye una pregunta recibida, una respuesta enviándose, otra fallida y un párrafo largo con una URL. Añade una segunda conversación con un borrador distinto. Estos ejemplos sacan a la luz decisiones que una galería limpia de burbujas alternadas no resuelve.

Utiliza el ejemplo como ejercicio de aceptación propuesto, con resultados verificables. Compruebas si el kit elegido permite expresar la conducta que necesitas y si tu equipo puede mantener la integración. Una biblioteca de Figma puede aportar la referencia visual; un paquete React puede aportar componentes de representación. Confirma el entregable real antes de repartir el trabajo de implementación.

Define el conjunto mínimo útil: encabezado de conversación, lista de mensajes, fila de mensaje, editor, información de entrega y regreso a la lista de conversaciones. Separa identidad, contenido y estado. La foto de perfil ayuda a reconocer a alguien, pero el remitente debe seguir siendo identificable cuando la imagen no carga o se omite.

Prueba contenido realista en ambos sentidos. Una confirmación breve y una explicación detallada de soporte exigen ajustes diferentes de líneas y espacios. Muestra un nombre, una indicación temporal útil y un fallo comprensible junto a la respuesta afectada. Son requisitos propuestos para este ejercicio; React no impone una presentación concreta de las conversaciones.

Si todavía falta validar la integración básica, empieza por la guía de aceptación de kits React para formularios, diálogos y estado. Aquí concretamos ese proceso en una conversación: conservar lo escrito, comunicar la incertidumbre de entrega y permitir revisar el historial mientras llegan mensajes nuevos sin perder el contexto.

Modela el envío y el reintento

React recomienda organizar el estado evitando contradicciones y copias redundantes. Aplica ese principio asignando a cada mensaje enviado un estado de entrega: pendiente, aceptado o fallido, por ejemplo. Acuerda su significado con quien mantiene el backend. En este modelo propuesto, aceptado significa que el servicio confirmó el mensaje; no implica que el destinatario lo haya leído.

Asigna a cada mensaje un identificador local estable y guarda por separado el identificador del servidor cuando sea necesario. La documentación de listas de React explica la importancia de las claves estables al insertar, eliminar o reordenar elementos. Conserva la clave de representación al recibir la confirmación; cambiarla sin criterio puede remontar la fila y perder estado de la interfaz.

Diseña el reintento antes de decorar el error. Una fila fallida debe conservar su texto y ofrecer una acción explícita. Reintenta el mismo mensaje lógico conforme al contrato de deduplicación del servicio. Una clave de React no evita escrituras duplicadas en el servidor. Pregunta qué sucede cuando vence el tiempo de espera después de que el servicio ya haya aceptado la petición.

En la prueba, desconecta la red después de enviar y vuelve a conectarla antes de reintentar. Anota qué contenido permanece visible, si la acción informa del progreso y si el historial contiene una sola respuesta lógica. Simula también un mensaje entrante durante el reintento. La respuesta saliente no debe adoptar la identidad de otra fila ni cambiar inesperadamente la selección.

Distingue la conexión general de la entrega individual. Un aviso de desconexión describe la sesión; la etiqueta de fallo pertenece a un mensaje. Todavía puede ser posible leer el historial cargado sin conexión. Evita marcar todas las filas como fallidas por cambiar el indicador general. La tabla siguiente propone un contrato de interfaz que debe confirmar el servicio real.

Crea un editor que conserve el borrador

Parte de un editor multilínea con etiqueta y un botón Enviar explícito. La referencia de textarea de React distingue el valor controlado del defaultValue inicial y exige actualizar el valor mediante onChange cuando se controla. Inicializa el borrador controlado como cadena de texto. El placeholder puede sugerir contenido, pero no debería ser la única etiqueta del campo.

Elige una política consciente para los borradores. En una bandeja de soporte, pasar de Alex a Sam no debe enviar por accidente a Sam el texto pendiente para Alex. Puedes conservar un borrador por conversación o reiniciarlo mediante una navegación clara. La guía de conservación del estado de React incluye un chat donde una key permite reiniciar el editor al cambiar de destinatario.

Para este ejemplo, conserva los borradores en un mapa indexado por el identificador de conversación. Es una decisión de producto, no una garantía incorporada de persistencia. Decide aparte si sobreviven a una recarga o al cierre de sesión. Documenta esa política, especialmente si guardar localmente implicaría conservar conversaciones sensibles en un ordenador compartido por varias personas.

Captura el texto enviado y su destino antes de iniciar la petición asíncrona. Si la persona escribe otro borrador mientras espera, una confirmación tardía no debe borrarlo. Una solución consiste en trasladar el texto enviado a la fila pendiente y limpiar solo ese borrador. Si falla, la información aparece junto a la fila que conserva el contenido del envío.

Si añades Intro para enviar, explica cómo insertar un salto de línea y prueba la composición de texto. Mantén el botón explícito. En una base multilínea, Intro puede seguir creando líneas nuevas. Comprueba edición solo con teclado, pegado de varios párrafos y corrección de respuestas fallidas. Lo relevante es que el borrador siga siendo comprensible y recuperable durante todo el proceso.

Separa el historial de los anuncios

El historial contiene información secuencial; los avisos de entrega describen el resultado de una acción. La técnica ARIA23 del W3C muestra una región con nombre y role=log para mensajes añadidos al chat. Su comportamiento live implícito y educado permite avisar a la tecnología de asistencia sin llevar el foco al contenido nuevo. La técnica también señala la importancia de comprobar compatibilidad real.

Mantén remitente y texto visibles en un orden de lectura significativo. Revisa el historial como lista de mensajes antes de añadir posiciones complejas. Un mensaje entrante no debería enfocar automáticamente su burbuja e interrumpir la escritura. En este ejercicio, conserva el foco en el editor después de un envío normal y ofrece una ruta deliberada para consultar el historial.

La orientación de WCAG sobre mensajes de estado explica cómo exponer avisos relevantes mediante programación sin recibir el foco. Aplícala a información breve como un fallo de envío. Evita anunciar el mismo suceso mediante la actualización de una fila y una alerta urgente independiente salvo que las pruebas lo justifiquen. Acumular anuncios no garantiza una experiencia más comprensible.

Para respuestas largas o actualizadas de forma continua, acuerda cuándo anunciar. Reemplazar un párrafo que crece carácter a carácter difiere de añadir un mensaje completo. Una prueba útil es anunciar la finalización o un estado breve y mantener disponible la respuesta íntegra. Es una política de interacción propuesta: verifica su resultado con la combinación real de navegador y lector de pantalla.

Mantén proporcionados los avisos rutinarios. Una confirmación de lectura no necesita interrumpir cada frase que se está escuchando. Registra qué oye la persona cuando llega una respuesta, falla un envío y se carga historial antiguo. Consulta la guía sobre alcance de kits y sistemas de diseño para decidir qué reglas compartidas de avisos debe documentar el equipo además de los recursos visuales.

Adapta la vista sin perder la posición

En una pantalla estrecha no hace falta mantener lista e historial en paralelo. Muestra una tarea útil cada vez, con regreso claro e identidad de conversación conservada. La orientación WCAG sobre reajuste del contenido describe la presentación vertical ordinaria a una anchura equivalente a 320 píxeles CSS sin perder información ni exigir desplazamiento en dos dimensiones.

Prueba esa anchura con un nombre largo, una URL sin espacios, la acción de reintentar y el texto de botón más largo de la traducción. Deja que el mensaje se ajuste al espacio disponible. El ancho máximo decorativo de una burbuja no debe ensanchar toda la página. Comprueba el navegador: reducir una captura de escritorio no demuestra que el contenido se reajuste.

Un editor fijo puede tapar el final del historial o un botón de reintento enfocado. La orientación sobre foco no oculto de WCAG exige, en su nivel mínimo, que el componente enfocado no quede completamente oculto por contenido creado por el autor. Diseña para que se vea entero y recorre los controles con teclado, sin convertir la visibilidad parcial en objetivo.

Conserva la posición de quien revisa mensajes antiguos cuando llega uno nuevo. Una política propuesta consiste en seguir las novedades solo si ya está al final; en otro caso, muestra una acción Nuevos mensajes. Cargar historial anterior también debería mantener un punto de lectura reconocible. Ninguna de estas decisiones aparece automáticamente por añadir un div con desplazamiento.

Incluye el teclado móvil al revisar el editor. ¿Se ve lo que se está escribiendo y se alcanza Enviar? Para acciones compactas con iconos, consulta la orientación WCAG sobre tamaño de objetivos: el criterio mínimo utiliza 24 por 24 píxeles CSS y contempla excepciones, incluido el espaciado. A menudo conviene un control cómodo mayor que depender de una excepción.

Relaciona recursos EmviUI y responsabilidades React

El catálogo público de EmviUI incluye avatares, botones, campos, alertas, estados vacíos y tratamientos de error. Utiliza esos recursos para dar coherencia visual a la conversación de prueba. Los ejemplos reales de campos mostrados antes permiten comparar etiquetas, ayuda y errores. No demuestran conducta implementada en React ni constituyen un servicio de mensajería preparado para producción.

Empieza por el editor, antes de decorar todas las burbujas. Adapta un campo multilínea, una acción visible y un tratamiento breve de fallo. Después compón una fila donde remitente y entrega sigan siendo legibles. Mantén una referencia visual pequeña para que diseño y desarrollo puedan revisar juntos los mismos ejemplos pendientes y fallidos en una sola sesión.

Escribe el mapa junto al ejemplo: apariencia del campo hacia el wrapper React de textarea, tratamiento de acción hacia el botón de envío y estilo del fallo hacia el componente de estado del mensaje. Asigna borradores y modelo de entrega a la aplicación. Así aprovechas el kit sin atribuirle autenticación, almacenamiento, transporte ni garantías sobre la entrega.

Una fila correcta no demuestra una solución completa de chat. Adjuntos, moderación, búsqueda, borrado y mensajes no leídos introducen decisiones distintas de producto y servicio. Añádelas cuando la tarea real las necesite. Para definir límites entre componentes de esas funciones, consulta la guía de componentes configurables y separados, y evita concentrar toda la conversación en un componente con responsabilidades ambiguas.

Acepta el kit con resultados observables

Realiza una sesión breve de aceptación sobre la aplicación integrada. Abre una conversación, escribe un borrador, cambia de destinatario, vuelve y envía. Después fuerza un fallo, reintenta, recibe una respuesta y revisa el historial anterior. Observa el resultado visible y el anunciado. Utiliza condiciones de red reproducibles para que dos revisores puedan comparar exactamente la misma secuencia.

Registra el resultado esperado antes de cada caso. Al cambiar de destinatario, el editor muestra el borrador correspondiente; tras un fallo, el texto enviado sigue siendo recuperable; si llega algo mientras se lee el historial, la vista permanece anclada. Estas expectativas constituyen el contrato elegido por tu equipo. No prueban que un kit concreto ya las cumpla sin trabajo adicional.

Acepta el kit cuando sus piezas visuales encajen con el ejemplo y la interfaz React compuesta supere las comprobaciones acordadas. Asigna los huecos pendientes a responsables concretos. Una burbuja cuidada aporta valor, pero el resultado decisivo es una conversación que conserve la escritura, comunique incertidumbre y siga siendo utilizable cuando cambian contenido, anchura de pantalla y condiciones de conexión.