- How do I install and configure laravel-livewire-tables?
- Run composer require alp-develop/laravel-livewire-tables, then publish the config with php artisan vendor:publish --tag=livewire-tables-config. That publish step is required because config/livewire-tables.php defines the theme, colours, and dark mode settings. Tailwind users must also add [x-cloak] { display: none !important; } to their CSS. After that, scaffold a table with php artisan make:livewiretable UsersTable User and define configure() and query() in the generated component.
- Which Laravel, Livewire, and PHP versions does this package support?
- The package claims Laravel 10 through 13, Livewire 3 and 4, and PHP 8.1 through 8.5. Treat the Laravel 13 and Livewire 4 claims as unverified until you prove them in your own CI matrix, since they may rest on widened Composer constraints rather than tested builds. The integration itself is conventional Livewire 3 code, so standard version pinning applies.
- Does it support Tailwind, Bootstrap 5, Bootstrap 4, and dark mode?
- Yes. Set the theme key in config/livewire-tables.php to tailwind, bootstrap-5 (aliases bootstrap5 and bootstrap), or bootstrap-4 (alias bootstrap4), and dark mode is toggled from the same file. Tailwind requires the [x-cloak] CSS rule. Public evidence that the Bootstrap themes are exercised by the package's own tests is not established, so verify the rendering in your target theme.
- Why do two tables on the same page share filters, sort, or pagination?
- Table state is stored in the session by default, so multiple instances of the same component share filters, sorting, and the current page unless each instance is given a unique table key. This is documented but easy to miss in dashboards that render the same table twice or in multi-tenant views. Pass a distinct key per instance to isolate state.
- Is ActionColumn safe when buttons are built from row data?
- ActionColumn's button callback string-builds JavaScript from row values, which is safe for integer primary keys but becomes an injection vector the moment you interpolate a string column. Add a hard code-review rule that these callbacks only emit integers or escaped, json_encode()d values. Never pass user-supplied text directly into the generated JavaScript.
- How does the package handle query performance and pagination?
- Tables are compiled by an Engine through a pipeline of SearchStep, FilterStep, and SortStep stages over a read-only State object, and the Engine is cached per request and reused by render(), getSelectedIds(), and export. applySteps() deliberately skips the pagination step, avoiding a redundant COUNT(*) query. Column definitions are code, so query shape stays reviewable and testable in CI. Watch select-all behaviour on very large filtered sets, since full ID materialisation in memory is an open question.
- Can I customise table behaviour without forking the package?
- There are three sanctioned extension points: override configure() in your table component, register a custom StepContract implementation, or override getEngine(). Contracts such as StepContract, FilterContract, ColumnContract, and StateContract give clear seams, so most gaps can be filled without a fork. That is also the exit path: coupling is one base class plus one Blade tag, so replacing the package means rewriting table components, not re-architecting the application.
- What is the risk of the Livewire\Tables namespace?
- Package classes ship under Livewire\Tables, which sits inside Livewire's own vendor root. Composer merges the PSR-4 prefixes so it resolves today, but autoload paths then span two physical roots, IDE navigation drops you into vendor, and any future Livewire\Tables release from the Livewire team would be a hard collision. It is not a blocker, but if you adopt the package seriously, plan to fork and re-namespace. Keep that fork cost in the adoption budget.
- Is there test coverage and CI for this package?
- The repository ships a GitHub Actions tests workflow, visible as a badge in the README. The coverage percentage is not published, and it is unclear whether the Bootstrap themes are exercised by the suite, so run the package through your own smoke tests before adopting. The evaluation also recommends reading docs/*.md rather than trusting the README, whose Quick Start snippet contains a syntax error.
- Is laravel-livewire-tables production-ready, and who maintains it?
- It is a single-author MIT package (alp-develop) with minimal adoption evidence — around seven stars and zero dependents — so there is no third-party production trail and you will effectively be the first real user. MIT licensing preserves fork rights, which is the main mitigation, along with the small coupling surface if you later swap it out. Check whether a semver or deprecation policy exists before committing, and budget time for reading the docs and debugging issues without community support.