- How do I install LaraGrid in a Laravel application?
- Install it with composer require unnathianalytics/laragrid. There is no npm step, no Vite build and no Blade wiring, because the package ships its own vanilla JavaScript grid engine. You then configure the grid inside your Livewire component class using chained methods such as column definitions, sorting, filtering and pagination. The whole integration surface is Composer plus your component class, which makes it attractive if your team has no frontend build pipeline.
- Which Laravel and Livewire versions does LaraGrid support?
- LaraGrid is built for Laravel with Livewire and its RPC plus wire:ignore model is tightly coupled to Livewire internals. Always check the composer.json constraints and the README requirements section for the exact PHP, Laravel and Livewire majors supported before installing. Because the package is early-stage with a single maintainer, confirm the maintainer's stated support policy and how quickly a Livewire major release will be tracked. Prototype on your actual Laravel and Livewire versions rather than assuming forward compatibility.
- Can LaraGrid cells participate in normal Livewire reactivity or wire:model binding?
- No, and that is deliberate. The grid body lives inside a wire:ignore region, Livewire never morphs a row, and a framework-free JavaScript engine owns every cell it paints while all reads and writes go back to the server over renderless RPCs. This is what gives you Excel-style keyboard navigation and range selection without a round-trip on every keystroke. The trade-off is permanent: grid cells will not compose with Alpine, reactive form state or other Livewire child components, so plan the surrounding UI accordingly.
- How does LaraGrid validate and authorize edits on the server?
- Every edit is routed through a whitelisted, fail-closed pipeline where the server validates, authorizes and recomputes the affected values. Columns and rows outside that whitelist should be rejected rather than silently accepted. Treat this as a claim to verify rather than assume: attempt to POST an out-of-scope column, an edit to an unauthorized row, and a stale version, and confirm the pipeline fails closed in each case. Getting those adversarial tests into your suite before launch is the single most important pre-commitment check.
- Can LaraGrid render a readonly, server-side grid with sorting, filters and pagination?
- Yes. The readonly server-side mode covers sorting, global search, column filters, pagination, bulk row selection and footer totals. All of that traffic runs through the same whitelisted fail-closed pipeline, so the data shown is server-authoritative rather than client-computed. It is the right mode for dense report-style tables where operators expect spreadsheet muscle memory but should not edit anything.
- Does LaraGrid support editable cells, async pickers and live formula columns?
- Yes. The editable mode gives you typed cell editors, an ERP-style focus mode for keyboard-driven entry, async pickers that enrich the row on select, live formula columns that recompute as values change, auto-appended blank rows and a running footer. Everything is declared in the component class, so you are not writing JavaScript or Blade partials per column. Because the client engine is the sole source of truth for display, make sure any server-side recompute you trigger is pushed back through the RPC layer.
- What happens when two users edit the same row at the same time?
- Concurrency handling is not part of the documented public contract, so assume nothing. The grid does not morph rows through Livewire, which means a conflicting write will not produce a diff that self-corrects on screen. Decide explicitly between optimistic locking with a version column, last-write-wins, or a server-side conflict flag, and test the chosen behaviour with two sessions editing the same row. If stale cells are possible in your domain, surface a reload affordance rather than trusting the rendered state.
- How do I test LaraGrid behaviour in CI?
- Split the testing strategy in two. Test the renderless RPC endpoints directly for validation, authorization, whitelist enforcement and recomputation, since those are plain HTTP calls and are cheap to assert in Pest or PHPUnit. Anything about rendered cells, focus movement or keyboard navigation crosses the wire:ignore boundary, where Livewire test helpers cannot see the DOM, so browser tests with Dusk or Pest browser are effectively mandatory for that layer. Budget for that suite before adopting.
- Is LaraGrid accessible to screen readers and keyboard-only users?
- The package is explicitly keyboard-first, which is not the same as being screen-reader accessible. A grid with a custom focus and range-selection model frequently fails WCAG because focus is owned by JavaScript rather than native table semantics. Accessibility and internationalisation are not addressed in the documentation, so run an audit against your target standard and check whether a documented escape hatch exists for cells that need a conventional control. If accessibility is a hard requirement, prototype with a screen reader before committing.
- Is LaraGrid production-ready, and how does it compare to other Livewire datagrid packages?
- LaraGrid is a focused, single-maintainer package with a small adoption footprint, so treat it as a pre-adoption dependency rather than a settled ecosystem default. Its differentiator is architectural: unlike Livewire-owned tables such as Filament or Livewire Tables, it hands the grid body to a standalone JavaScript engine behind wire:ignore and keeps a server-authoritative RPC layer. That is a strong fit for spreadsheet-trained operators on large datasets, and a poor fit if you need Livewire or Alpine reactivity inside cells, so weigh the trade-off against your own use case.