Product Decisions This Supports
- Build vs. buy for table/list surfaces. This is a narrow, credible "buy" only if the stack is already Laravel + Inertia + React + shadcn/ui. It replaces roughly the 1–2 weeks of plumbing (server-side pagination, sortable columns, debounced search, filter serialization, query-param round-tripping) that gets re-written on every project and subtly wrong each time.
- Standardization of list-view UX. A shadcn registry component (DataTable, Toolbar, Pagination, ColumnHeader, ColumnVisibility, Empty) plus a
useDataTable hook is an opinionated default. Adopting it is a decision to stop letting each squad invent its own table chrome.
- Security posture for ad-hoc DataTables endpoints. The strict column allow-list is the most product-relevant line in the release. Hand-rolled sort/search endpoints are a recurring source of unvalidated-column injection and information disclosure. Choosing a package that makes the allow-list the default removes a class of finding from future pen tests.
- Scope signal for roadmap. Absence of exports, row actions, inline editing, aggregates, joins/relation filters, and saved views defines the boundary: this serves read-only, paginated, filtered browsing on Eloquent/Query Builder. Anything richer is still ours to build.
- Not a driver for: framework selection, Inertia adoption, or React adoption. This package follows those decisions; it should never cause them.
When to Consider This Package
Consider it when all of the following hold:
- Frontend is Inertia 3 + React 19, with TanStack Table v8 and shadcn/ui already present (or acceptable to introduce).
- Backend is Laravel 12.x on PHP 8.4+, and the team is comfortable running current-generation runtimes.
- You have more than two or three list surfaces, or one high-traffic table needing server-side pagination against large Eloquent sets.
- Your need is browse/search/sort/filter with text, select, and boolean filters — no row mutations.
- You can pin an exact version and absorb breaking changes pre-1.0.
Look elsewhere when:
- The app is Inertia + Vue or Svelte. This is React-only; adoption cost is a stack migration, not a dependency.
- You are on Laravel 10/11 or PHP < 8.4. The stated floor excludes most current fleets.
- You need a full admin framework (auth scaffolding, forms, policies, actions) — that is Filament or Nova territory, not a table.
- You need the jQuery DataTables wire protocol or a Blade-rendered table — that is
yajra/laravel-datatables.
- Your procurement or security review requires a stable (≥1.0) dependency, or the "Laravel 13.x" claim cannot be satisfied against a released framework version.
- You need column reordering persistence, virtual scrolling, grouping, pivot, CSV/Excel export, or relation-column sorting — verify before committing; none are documented here.
Diligence before adoption: confirm test coverage and CI signal, Laravel Policy/authorization hooks, soft-delete and global-scope behavior, composite-key support, relation/join filtering, and whether configurable query parameter names break Inertia's partial-reload key matching. Treat the shadcn components as vendored code you now own.
How to Pitch It (Stakeholders)
To executives: A small, early-stage open-source library that removes repetitive work from building data tables in one specific part of our stack. It is not a platform bet and not a vendor commitment. Cost to evaluate is a short engineering spike on a branch; cost to walk away is near zero because the UI pieces are copied into our repo and the server-side logic is thin. Its clearest business value is a security default — safe, allow-listed sortable/filterable columns — that eliminates a repeated category of vulnerability in hand-built admin tables. Recommendation: fund a spike, not an adoption.
To engineering: The package is glue, not a framework. The durable parts are the Eloquent/Query Builder query layer and the shadcn registry components; the TanStack Table integration is standard. Because shadcn's model is copy-in, we own and can fork the UI regardless of the package's future. Main risk is pre-1.0 API churn at v0.0.1 — mitigate by isolating it behind an internal table adapter/composable and pinning the version exactly. The "Laravel 13.x" compatibility claim is speculative and should not be quoted in planning. Please return from the spike with: coverage of our trickiest table (relations, scopes, composite keys), authorization story, and an estimate of the wrapper cost.