- What is savannabits/primevue-datatables used for?
- It is a thin Laravel package that implements server-side processing for PrimeVue DataTable running in lazy mode. It translates PrimeVue request parameters such as page, per_page, sortField, sortOrder and filters into Eloquent query building, giving you paginated, sortable and searchable grids with minimal configuration. Typical fits are admin panels, CRM-style record browsers and reporting views built on read-mostly Eloquent queries.
- How do I install and set up the package in a Laravel app?
- Install it as a Composer dependency, then point a controller at your Eloquent query and define the column and filter mapping the package should accept. On the frontend, PrimeVue DataTable must be in lazy mode and its dataKeys must match the backend whitelist of column names. Most of the setup effort goes into aligning those keys and deciding which columns are sortable and filterable.
- Which Laravel and PHP versions does this package support?
- Version 1.5.0 added Laravel 10 support, which was the newest framework version handled at that release. The supported matrix has historically lagged Laravel releases, so Laravel 11, Laravel 12 and newer PHP versions should be treated as unverified until you exercise them in your own CI. Check the repository composer.json constraints and test suite before committing to it.
- Which PrimeVue versions and DataTable request contract are supported?
- The package targets PrimeVue DataTable lazy loading, reading page, per_page, sortField, sortOrder and filters from the request. PrimeVue's lazy request and response contract has changed across major versions, and the package does not guarantee support for every release. Verify the contract against the exact PrimeVue version you ship, particularly the shape of filter metadata.
- Does the package handle authorization, tenancy or row-level permissions?
- No. It builds queries from request input but does not enforce policies, tenancy scoping or row-level permissions. You must apply authorization and query scoping in your controller or query builder before handing the query to the package. Treating it as a security boundary is a latent defect in any application.
- How does the case-insensitive JSON filtering work and is it index-friendly?
- Version 1.5.0 introduced case-insensitive JSON filtering so JSON-backed metadata fields can be filtered directly in list views. The implementation is driver-specific, and case-insensitive JSON predicates on MySQL, PostgreSQL and SQLite can bypass indexes and force full scans. Benchmark against production-like row counts on your primary driver and add generated columns or functional indexes where needed.
- Should I whitelist sortable and filterable columns?
- Yes, always whitelist sortable and filterable columns explicitly instead of trusting request input, because the package turns those parameters into query clauses. A whitelist prevents unexpected column access and keeps the generated SQL predictable and reviewable. Keep the whitelist in one place so it can be tested and audited.
- Is the package actively maintained and what is the release cadence?
- It is small, community-maintained and low velocity, with no releases since July 2023 and version 1.5.0 shipped by first-time contributors. It has no known dependents, so there is no external production signal to rely on and internal verification carries the full burden. Pin the version, keep regression tests around sort and filter behaviour, and plan for the maintainer bus factor.
- How should I test server-side sorting and filtering in my application?
- Write feature tests that hit your endpoint with representative page, sort and filter payloads and assert both the returned rows and the total count. Cover every whitelisted column, JSON filter cases and empty result behaviour against the same database driver you use in production. Run them in CI so a Laravel or PHP upgrade surfaces breakage immediately.
- What if maintenance stalls or a new Laravel release breaks it, and what are the alternatives?
- Isolate the package behind a small internal abstraction such as a query-builder service or base controller so replacing it stays a contained change. If maintenance stalls, fork it, pin your patch and assign a named owner for that contingency. Alternatives include writing your own server-side pagination handler with Laravel's paginator or choosing a more actively maintained datatable package.