Inertiajs Tables Laravel Query Builder Laravel Package

Product Decisions This Supports

• Build vs. buy on internal tooling. Every SaaS/admin product accumulates list screens — users, orders, invoices, audit logs. Each one re-implements the same four primitives: server-side pagination, sorting, filtering, and search. This package lets you buy that layer (MIT, zero license cost) instead of spending 2–4 sprints rebuilding it per resource.
• Roadmap sequencing for back-office features. If the next quarter is heavy on admin panels, reporting views, and customer-facing data tables, this is a lever that compresses the estimate for every one of those epics rather than a single feature.
• Feature scope calls on "advanced table" asks. When a stakeholder requests column visibility, saved filter sets, or export, you can classify it as incremental (config on top of an existing table abstraction) versus net-new — a materially different estimate.
• Standardization as a product decision. Adopting a shared table convention means consistent interaction patterns (sort affordances, filter chips, pagination) across the entire app — a UX consistency win that's hard to get from bespoke per-team implementations.
• Platform bet on the Laravel + Inertia stack. Committing to this package reinforces the Inertia/SPA-without-API architecture. That's a defensible decision for CRUD-heavy products and a constraint to acknowledge for real-time or highly interactive grid use cases.
• Use cases it fits: admin/ops dashboards, multi-tenant customer portals with list views, internal support tooling, moderation queues, transactional history screens.

When to Consider This Package

Adopt when:

• Your stack is already Laravel + Inertia.js + Vue or React, and you have (or will adopt) spatie/laravel-query-builder as the query layer — this package is essentially the UI contract on top of it.
• You have many list screens rather than one. The value scales with screen count; a single table doesn't justify a new dependency.
• Front-end bandwidth is the bottleneck. The pitch is "the table is a component, the logic is server-side" — your Laravel devs can ship list screens without JS specialists.
• You're comfortable treating a small, MIT-licensed dependency as vendorable — fork it if needed and own the delta.

Look elsewhere when:

• You're not on Inertia, or you need a framework-agnostic/headless table layer (evaluate TanStack Table directly).
• The table is a product centerpiece requiring virtualization for 10k+ rows, row grouping, column resizing/reordering, inline spreadsheet-style editing, or pivot/aggregate grids. That's AG Grid / DataTables / bespoke territory, not a query-builder wrapper.
• You require vendor support, an SLA, or a dependency with a large maintainer community. At ~28 stars this is a single-maintainer-risk asset; budget for the possibility you inherit it.
• Your data access patterns don't map to simple Eloquent/query-builder resources — complex computed columns, cross-service aggregation, or search-engine-backed lists will fight the abstraction.

Diligence before committing: confirm lineage relative to the well-known upstream Inertia tables package, check issue responsiveness and release cadence, and read the upgrade path. Pin the version and note the fork cost in the ADR.

How to Pitch It (Stakeholders)

To executives: This is a free, open-source component that removes repeated engineering work from every admin and reporting screen we build. It replaces a "build the table from scratch each time" pattern with a consistent, configurable one — meaning faster delivery of back-office features, a more uniform product experience, and less code we permanently own. Cost is zero in license fees; the investment is a few days of integration plus a documented fallback (MIT license lets us fork if the maintainer steps away). Recommend a time-boxed pilot on one non-critical admin screen with a go/no-go review before broader adoption.

To engineering: It's an Inertia table component backed by spatie/laravel-query-builder — sorting, filtering, searching, and pagination happen server-side via query-string conventions, so the front end stays thin and the database does the work. You define allowed filters/sorts/includes in PHP and column definitions in the component; no bespoke fetch logic per screen. Trade-offs: it's a small-community package (28 stars), so we pin the version, avoid deep customization until we've read the source, and accept that a fork is a realistic maintenance option. It also presumes we're standardized on query-builder as the resource-query convention — worth aligning on that first, since it's the real architectural commitment.

Ask: approve a scoped pilot (one screen, one engineer, ~1 week) with success criteria of time-to-ship versus our last bespoke table and zero blocking gaps.