RussianPost, Portal corporativo para envíos postales estatales

Desafío

El portal interno de Russian Post, usado por decenas de miles de empleados, había crecido de forma orgánica durante años. Cada módulo manejaba los datos tabulares de forma distinta: distinta lógica de paginación, distintos patrones de filtrado, distintos modos de edición. El resultado era una experiencia de usuario inconsistente y un coste de mantenimiento creciente cada vez que se necesitaba una nueva pantalla de datos.

Además, el trabajo se realizaba bajo estrictas restricciones empresariales: aprobaciones de cambios en varios niveles, versionado de la API de SharePoint y políticas de seguridad que descartaban la mayoría de las herramientas SaaS de terceros.

Descubrimiento

Tras mapear las pantallas existentes quedó claro que casi todas necesitaban lo mismo: paginación del lado del servidor, ordenación y filtrado de columnas, modo de edición en línea y vistas por pestañas que cambiaban el conjunto de datos sin recargar la página. El problema no eran los datos, era la falta de un contrato compartido sobre cómo mostrarlos.

Opciones consideradas

1. Usar Kendo Grid directamente en todas partes: descartado. Cada equipo lo integraba de forma distinta, perpetuando la inconsistencia.
2. Construir una tabla personalizada desde cero: descartado. Demasiado arriesgado dado el calendario empresarial y la amplitud de funciones requeridas.
3. Envoltorio estandarizado sobre Kendo Grid: elegido. Encapsular todo el comportamiento común detrás de una única API tipada, mantener Kendo como motor y aplicar la consistencia mediante la capa de abstracción.

Decisión

El enfoque de envoltorio ofreció la mejor relación entre control y riesgo. Kendo se encargaba del renderizado y la virtualización; el envoltorio poseía el contrato de la API: metadatos de campos, modos de paginación servidor/cliente, conversión de tipos, renderizadores de celda personalizados y columnas de estado. Se añadió encima una capa adaptadora de Redux separada (CustomGridRedux) para las pantallas que necesitaban que el estado de la tabla (selección, paginación, orden) viviera en el store, manteniéndola compatible con las tablas que no lo necesitaban.

Implementación

CustomGrid acepta campos con metadatos, un array de datos y un método de carga. Admite dos modos de paginación, servidor (el total viene de la API, la tabla orquesta la obtención de datos) y cliente (dataQuery de Kendo lo maneja todo localmente), más un modo combinado para añadir cambios locales a los datos del servidor. La conversión de tipos desde las estructuras del servidor a tipos de JS ocurre automáticamente mediante mapeos de campos, ahorrando código de transformación repetitivo en cada pantalla.

useCustomGridFilters es un hook memoizado que envuelve un conjunto de definiciones de filtros con nombre y renderiza una barra de herramientas de Kendo con recuentos en vivo por pestaña. Cambiar de pestaña modifica el conjunto de datos que alimenta la tabla sin recargar la página ni hacer peticiones adicionales.

CustomGridRedux es un adaptador ligero que envuelve CustomGrid y refleja la selección, la paginación, el orden, el filtro, el modo de edición y el estado de los campos en Redux, a través de acciones, reducers y selectores reselect dedicados, permaneciendo totalmente compatible con los usos existentes.

Recorrido del componente

Casi todo el trabajo se hacía en servidores Windows remotos. El cliente de escritorio remoto se volvió casi una segunda casa, porque cada tarea empezaba conectándose a un servidor remoto.

Resultado

Ahora cada pantalla de datos del portal usa el mismo componente con la misma API. Añadir una nueva vista de tabla pasó de ser una tarea de integración de varios días a pasar una configuración de campos y una función de carga. El rol de Scrum Master junto con el trabajo técnico mantuvo estable la velocidad de entrega bajo bloqueos constantes del lado empresarial. Las ceremonias se mantuvieron ágiles y los impedimentos se resolvían antes de frenar los sprints.