I've integrated a lot of data grids over the years.
Every time, the experience was the same — open the docs, search for the
prop I need, find three different ways to do the same thing, pick one,
get it wrong, Google it, eventually get it working, and forget how I did
it by the next project.
I'm a developer. I shouldn't need tribal knowledge to configure a UI component.
So I started building EliteGrid.
The core idea: grouped config API
Most grids dump every option at the top level. Hundreds of flat props with
no consistent naming pattern. You end up memorizing prop names instead of
understanding a mental model.
EliteGrid uses a grouped, namespaced config API. Every feature has its own
namespace:
<EliteGrid
data={rows}
columns={columns}
sorting={{ multi: true }}
filtering={{ debounce: 300 }}
pagination={{ pageSize: 25 }}
selection={{ mode: 'multi' }}
editing={{ trigger: 'doubleClick' }}
appearance={{ theme: 'dark', density: 'compact' }}
/>
Config that reads like English. TypeScript autocompletes every property.
You never need to guess a prop name.
The architecture
EliteGrid is built on a microkernel with 13 independent plugins communicating
through a shared event bus and data store:
- DataSource — raw data ingestion and normalization
- RowModel — row lifecycle, identity, and memoization
- ColumnModel — column definitions, width, visibility, pinning
- Sort — single and multi-column sort with custom comparators
- Filter — text, number, date, and boolean filters per column
- Pagination — client-side and server-side pagination
- Selection — single and multi-select with keyboard support
- Edit — inline editing with sync/async validation
- Viewport — visible row calculation and scroll management
- Export — CSV export with custom formatters
Each plugin is completely independent. No circular dependencies.
No hidden coupling. Zero runtime dependencies on the core.
We currently have 662 passing tests across the engine.
Accessibility by default
Full WCAG 2.1 AA compliance ships as part of the default experience.
Zero configuration required.
- Full ARIA Grid Pattern implementation
- Screen reader announcements for all state changes
- Complete keyboard navigation — Arrow keys, Home, End, PageUp, PageDown
- Roving tabindex focus management
- prefers-reduced-motion respected
- Windows High Contrast mode supported
Every user deserves a great grid, not just sighted mouse users.
Docs as a first-class feature
The goal: a junior developer should be able to integrate EliteGrid
from the docs alone — no AI, no Stack Overflow, no tribal knowledge.
That's a high bar. We're treating it as a product requirement, not
an afterthought.
Where we are
- ✅ Core engine — 13 plugins, 662 passing tests
- ✅ Grouped config API
- 🔨 React and Vue adapters — building now
- 🔨 Interactive sandbox on StackBlitz — building now
- ⏭ Public npm launch — coming soon
Community version will be free and open source.
Follow along
If this sounds like the grid you've been waiting for, join the waitlist at elitegrid.dev — one email when the sandbox is ready, one at launch.
I'd love to hear what you think in the comments. What matters most to you in a data grid?
Top comments (2)
"Config reads like English" is a great north star for a data grid specifically, because data grids are where config complexity goes to die - AG Grid et al are insanely powerful and have a config surface you need the docs open to navigate. A readable, declarative API is a real differentiator if you can hold the line on it, because the hard part isn't making the simple case read nicely, it's keeping it readable when the requirements get gnarly (virtualization, server-side rows, custom cell editors, grouping). The trap is the API that's beautiful in the README and turns into nested-callback soup in real use.
The thing I'd push on, and it's increasingly relevant: a config that reads like English is also a config an AI can write correctly. Declarative, legible APIs are the ones LLMs generate well, because the structure is explicit and there's less hidden imperative state to get wrong - so "reads like English" doubles as "reads like something Copilot won't mangle." That legibility-for-humans-and-AI overlap is something I think about constantly building Moonshift, the thing I work on (a multi-agent pipeline that takes a prompt to a deployed SaaS). Multi-model routing keeps a build ~$3 flat, first run free no card. Cool project. How are you keeping the English-like API from leaking complexity once you hit the advanced cases (virtualized + server-side + custom editors)? That's the cliff every "simple" grid API eventually meets.
Really appreciate this — and we agree completely.
The “README looks clean, real-world config turns into callback soup” trap is exactly what we’re trying hard to avoid.
The way we’re approaching it is: keep the common path declarative, but let advanced cases “drop down” only where needed.
Example:
Simple use cases stay readable. More advanced behavior stays scoped to the feature namespace instead of leaking into the entire config surface.
Under the hood, the plugin boundaries help a lot too — virtualization doesn’t know about editing, server-side pagination doesn’t know about selection, etc. They communicate through the event bus/store, which lets each concern stay isolated instead of spreading complexity across the API.
And your AI point is a really interesting one. We didn’t originally frame it that way, but you’re absolutely right — a predictable declarative structure is easier for humans and for LLMs to generate correctly.
That overlap feels increasingly important.
Really appreciate the thoughtful push here — these are exactly the kinds of edge cases we’re designing for while building EliteGrid.