- How do I install ramonrietdijk/livewire-tables in a Laravel application?
- Require it with composer require ramonrietdijk/livewire-tables, then optionally publish its config and Blade views if you want to theme the output. You use it by adding the package trait to an existing Livewire component and declaring your columns in PHP. There is no separate JavaScript build step or npm dependency, so your existing front-end pipeline stays unchanged.
- Which Livewire and Laravel versions does ramonrietdijk/livewire-tables support?
- Support depends on the version constraints in the package's composer.json, and Livewire v2 versus v3 is the decisive constraint because the table layer hooks into component lifecycle events that changed between majors. Check the README and those constraints against the versions you run today before committing. Because it is a small, single-maintainer package, expect it to lag new Livewire majors by some months.
- How does ramonrietdijk/livewire-tables compare to rappasoft/laravel-livewire-tables or Filament?
- It is deliberately narrower: tables are composed directly on your Livewire component through a trait plus column and action classes, rather than a heavy configuration array or a full panel framework. You get sorting, searching, filtering, pagination and customizable columns and views, but not the export, bulk-action and panel scaffolding that Filament or rappasoft ship. That narrowness means less lock-in and less to unwind if you replace it, but more glue code at the edges.
- Does it include CSV export, bulk actions, or row actions out of the box?
- The package centres on table rendering: columns, sorting, searching, filtering and pagination. Bulk actions, CSV export and per-row authorization are generally left to the consumer, so you implement them in your own Livewire component or by extending the package's column and action classes. Budget for that glue work when estimating an admin screen.
- How do I customize the table markup to match my Tailwind design system?
- Publish the package views and edit the Blade markup, or wrap the rendered table in a thin Blade component that applies your own classes. One gotcha: Tailwind's content scanner will not see classes inside vendor Blade views, so you need to add the package view path to your tailwind.config content list or safelist the classes it uses. Without that, the table can render unstyled in production builds.
- Can it sort and search across Eloquent relationships server-side?
- Column definitions map to model attributes and the package performs sorting, searching and pagination through the underlying query, so straightforward relationship columns work with configurable eager loading. Complex relationship columns, custom filter UIs and non-standard cell rendering are typically where you write glue code or subclass a column type. Confirm the relationship and eager-loading behaviour against your own query shapes before relying on it.
- Is the package safe for production given its star count and single maintainer?
- It is MIT licensed and clean for commercial use, but the modest star count and single-maintainer release pattern mean a bus factor of one. Treat it as a niche package rather than a de facto standard and assume you may eventually own the code. Pin versions, keep your own tests around each table component, and watch the release cadence and issue-response history.
- Does Livewire query-string state work, so tables can be deep-linked and shared?
- Tables are plain Livewire components, so Livewire's URL query-string features apply: you can expose properties such as sort, search and page via the Url attribute or queryString to make table state shareable. The package itself does not add a bespoke deep-linking layer. Verify the internal property names it uses before wiring them into your URLs.
- How do I test a Livewire table built with ramonrietdijk/livewire-tables?
- Test the component the same way as any Livewire component: use Livewire's testing helpers to mount it, call set() on the search or sort properties, and assert the rendered output with assertSee or assertSet. There is no separate JavaScript runtime to stub out. Check whether the package ships its own test suite and whether CI is green on your framework matrix before depending on it.
- What are the main technical risks of adopting ramonrietdijk/livewire-tables in a large app?
- Maintainer concentration and Livewire major-version churn are the two biggest ones; a small package can lag breaking Livewire releases for months, and the table layer touches exactly the lifecycle hooks that change. Styling drift from Tailwind's content scanner is a lower-severity but recurring annoyance. None of this blocks incremental adoption, since each table is an independent Livewire component you can migrate one screen at a time.