Laravel Pagetables Laravel Package

Product Decisions This Supports

• Build-vs-buy sizing for admin table infrastructure. Every back-office surface on your roadmap — user rosters, order queues, audit logs, subscription lists — eventually needs the same thing: a DataTables front end wired to a Laravel paginator. This package is a useful reference point for scoping that work: it demonstrates the custom layer is on the order of a few hundred lines, not a quarter of engineering. That single data point lets you hold a defensible conversation between standardizing on yajra/laravel-datatables, adopting a richer grid (Filament, Livewire tables), or writing your own thin controller/transformer layer.
• Roadmap triage on "data tables" as a feature. Server-side pagination, sorting, and search are commodities. PMs should resist pressure to frame "our admin tables paginate" as a headline capability — it is table stakes, and pitching it upward as innovation costs credibility with engineering. Use this package's existence as evidence that the ecosystem treats DataTables as boring, stable plumbing.
• Deferring a grid migration. A tiny, single-purpose adapter like this signals that the ecosystem still considers DataTables a stable dependency. That supports not migrating internal tooling to a richer grid component until requirements genuinely escalate — saved views, faceted filters, aggregations, exports, drill-downs.
• Risk-register and ownership line item. Adoption is not a free dependency; it is an ownership commitment. Upstream activity is occasional constraint bumps rather than development, so the question "who pays the maintenance tax on compatibility patches?" is a product-ownership decision, and it should be recorded as one.
• Expectation-setting on delivery time. Because the package is a template rather than a supported platform, estimates for table-heavy epics should be built from your own base-class work — including testing the JSON endpoint contract — not from "there's a package for that."

When to Consider This Package

Consider it only when all of the following hold:

• You need server-side DataTables support against an Eloquent query or Laravel paginator, with no requirement for column-level search, faceted filters, joins with custom transformers, or CSV/Excel export.
• You are on Laravel 9 specifically. v1.1.0 (2022-06-13) was a no-op except for widening the constraint to allow Laravel 9; Laravel 10/11/12 are unclaimed and untested, so expect to widen illuminate/* yourself and re-apply that patch at every framework upgrade.
• Your team is comfortable vendoring or forking a few hundred lines of MIT-licensed code and owning it in-house. Frame it as copying a pattern, not taking a dependency.
• The surface is genuinely internal and low-traffic — no SLA, no external customers, no compliance review of third-party code paths.
• The decision is reversible in a sprint: you can swap to yajra/laravel-datatables or promote your own base class with one class changing.

Look elsewhere when:

• You are on Laravel 10+ and unwilling to fork. Install fails on constraints; the fix is trivial but permanent and recurring.
• The table layer needs to be a product differentiator — saved views, per-user column configuration, exports, aggregations. This is plumbing; a richer grid or a dedicated reporting layer is the right investment.
• Your organization requires an actively maintained dependency with a security-response posture. Three stars, zero dependents, and a release cadence measured in years do not clear that bar.
• Multiple teams will build tables independently. A thin adapter with no opinionated filter API invites divergence; standardize on a maintained library or an internal shared package with a named owner instead.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed utility that saves a few days of engineering on internal admin screens and nothing more. It is not a strategic platform choice and should not appear in roadmap narratives. Recommendation: do not adopt it as a dependency. Instead, have one engineer spend an hour reading its source as a reference design, then either use the industry-standard DataTables adapter or write our own small layer that we control. Net cost is roughly the same; net risk is lower.

To engineering: Treat this as a template, not a dependency. It is a thin wrapper that translates DataTables request parameters (draw, start, length, search[value], order[0][column]) into a paginated query and a JSON payload. Everything that matters — whitelisting sortable columns, qualifying joined column names, separating recordsTotal from recordsFiltered, clamping length=-1, killing N+1 with with()/withCount(), and echoing draw verbatim — will land in our base class, not upstream. Plan one Pagetable subclass per resource (never a generic model-parameterized endpoint, which is an SQL-injection vector), test the endpoint with JSON assertions rather than the UI, and keep the migration path to yajra/laravel-datatables down to a single class. Note deliberately chosen method names from src/ in our ADR, since the README may drift — and record the pinned version and widened constraints so a future constraint bump is a one-file diff, not a re-audit.