¶Why Elyra DataGrid

¶The problem

The data grid is the most demanding UI component most applications ever ship. It has to sort, filter, group, aggregate, page, edit, select, export, and stay responsive — often over data that does not fit in the browser. In the Laravel ecosystem, the existing options force a compromise:

• Client-bound grids load rows into JavaScript and do the work there. They are pleasant at small scale and fall over at large scale: you cannot filter, sort, or aggregate ten million rows in a browser tab.
• Ecosystem-locked grids are excellent but married to one stack — one frontend framework or one admin panel — so you cannot reuse them across a Livewire app, a Vue/Inertia app, and a Svelte app.
• Headless table cores give you primitives and leave everything else — server integration, filtering UI, editing, export, theming — as homework.

None of them are, at once: server-driven, scalable to millions of rows, reusable across frameworks, and native to your app's design system.

¶The approach

Elyra DataGrid closes that gap with four decisions.

¶1. One protocol, many clients

Every client speaks the same small JSON contract. A client says what it wants (columns, sort, filters, a viewport window, opt-in extras); the server answers with a slice of rows. That contract is defined once and generates both the TypeScript types and the PHP DTOs — so the Livewire, Vue, and Svelte clients are genuinely interchangeable and always in sync. You are not locked into one frontend.

¶2. Server-driven by design

Sorting, filtering, grouping, aggregation, search, and paging execute in the database, never in JavaScript. The client only ever renders a viewport. That is why the grid behaves the same over 100 rows and 10,000,000 rows — the work is O(viewport), not O(data).

¶3. Native to ElyraSQL

The server package leans on ElyraSQL's analytical and AI primitives, turning database features directly into grid features:

• Faceted value lists (FACET) — the "filter by checkbox, with counts" experience in a single pass.
• Group subtotals (WITH ROLLUP) and percentile/median columns and footers.
• Hybrid semantic + full-text search (HYBRID) — a search box that understands meaning, not just substrings.
• Streamed exports from a server cursor — export the full result set, millions of rows, with constant memory.

A generic MySQL fallback keeps it portable.

¶4. Follow the app

The theme is Tailwind v4 native and inherits your palette, accent, and dark mode automatically. The grid looks like it belongs in your application on day one, and can be re-skinned with a single accent token.

¶Why it is fast — structurally, not by accident

• Opt-in cost. Nothing expensive runs unless a feature needs it. Row counts and footer aggregates are cached per filter; facets load lazily when a dropdown opens. Changing page or sort does not re-run them.
• Virtualization. Only visible rows are rendered, and only visible columns for very wide grids. The DOM stays small no matter the dataset.
• Push-down. Every data operation is a database query, not a JavaScript loop.
• Instant first paint. The first page can be server-seeded (SSR/Inertia), so the grid is populated before the first client round-trip.

These are properties of the architecture, so performance does not degrade as your tables grow.

¶What it is — and what it is not

It is a full, server-driven grid for Laravel: sorting, a filter row with operators and faceted value lists, multi-level grouping, three editing modes, selection with keyboard and clipboard, master-detail and tree grids, cell templates, column operations, streamed export, theming, i18n, and state persistence — across three official clients.

It is not a client-only widget you drop onto a static page. It expects a Laravel backend and (ideally) ElyraSQL. That is the trade that buys you scale.

¶Who it is for

• Teams building data-heavy Laravel applications — dashboards, admin tools, analytics, back-office — where grids must stay fast at real volume.
• Organizations running more than one frontend (Livewire and Inertia) that want one grid, one contract, one design system across all of them.
• Anyone who needs analytical and AI-native grid features (facets, percentiles, semantic search, large exports) without bolting on a second system.

¶The philosophy

Simple by default, configurable to advanced. A working grid is four lines. Every feature is false | true | { …options } — omit it, accept sensible defaults, or take full control. Cost is opt-in, security is by allow-list, and the grid follows your app.

Continue to the Introduction & architecture, or jump to the Quick start.