RussianPost – Corporate Portal for Government Postal Deliveries

Challenge

Russian Post's internal portal — used by tens of thousands of employees — had grown organically over years. Each module handled tabular data differently: different pagination logic, different filter patterns, different edit modes. The result was an inconsistent UX and mounting maintenance cost every time a new data screen was needed.

On top of that, work was done under strict enterprise constraints: multi-level change approvals, SharePoint API versioning, and security policies that ruled out most third-party SaaS tooling.

Discovery

After mapping the existing screens it became clear that almost every one needed the same things: server-side pagination, column sorting and filtering, inline edit mode, and tabbed views that switched the dataset without reloading the page. The problem wasn't the data — it was the lack of a shared contract for how to display it.

Options Considered

1. Use Kendo Grid directly everywhere — rejected. Each team integrated it differently, perpetuating the inconsistency.
2. Build a custom grid from scratch — rejected. Too risky given the enterprise timeline and the breadth of required features.
3. Standardized wrapper around Kendo Grid — chosen. Encapsulate all common behaviour behind a single typed API, keep Kendo as the engine, and enforce consistency through the abstraction layer.

Decision

The wrapper approach gave the best ratio of control to risk. Kendo handled rendering and virtualization; the wrapper owned the API contract: field metadata, server/client pagination modes, type casting, custom cell renderers, and status columns. A separate Redux adapter layer (CustomGridRedux) was added on top for screens that needed grid state (selection, pagination, sort) to live in the store — making it backward-compatible with grids that didn't.

Implementation

CustomGrid accepts fields with metadata, a data array, and a load method. It supports two pagination modes — server (total comes from API, grid orchestrates fetching) and client (Kendo's dataQuery handles everything locally) — plus a combined mode for appending local changes to server data. Type casting from server shapes to JS types happens automatically via field mappings, saving repetitive transformation code on every screen.

useCustomGridFilters is a memoized hook that wraps a set of named filter definitions and renders a Kendo toolbar with live item counts per tab. Switching tabs changes the dataset fed to the grid without any page reload or extra fetch.

CustomGridRedux is a thin adapter that wraps CustomGrid and mirrors selection, pagination, sort, filter, edit mode, and field state into Redux — via dedicated actions, reducers, and reselect selectors — while remaining fully backward compatible with existing usages.

Component walkthrough

Outcome

Every data screen in the portal now uses the same component with the same API. Adding a new table view went from a multi-day integration task to passing a field config and a load function. The Scrum Master role alongside the technical work kept delivery velocity stable under constant enterprise-side blockers — ceremonies stayed lean, impediments got resolved before they stalled sprints.