Filament Spreadsheet Grid Laravel Package

Product Decisions This Supports

• Build vs. buy for spreadsheet-grade inline editing. This package now handles the long tail of grid-editing edge cases a team would otherwise rebuild: paste, fill down/right, dirty-cell tracking, and per-source-cell state. That shifts the decision toward buy for any roadmap item that promises "edit like a spreadsheet."
• Data-integrity commitments you can make to customers. v1.0.1 closes several silent corruption paths — ambiguous input like 1.250 is no longer coerced to 1.25, unknown boolean words no longer become false, and an invalid cell is never re-read as a valid grid value on paste or fill. This is the difference between "we accept spreadsheet input" and "we can be trusted with financial or inventory quantities."
• Validation parity as a product guarantee. Client and server now agree on required() (whitespace-only rejected on both sides), user rules like unique:products / exists:skus resolve under the column's own name, and a save cancelled by a model event is reported as failed, not saved. That last one matters for any UI that shows a success toast — false confirmations are a support-ticket generator.
• Workflow coverage for soft deletes and joined data. Rows surfaced by a filter's base query (TrashedFilter "With trashed") are now saveable, and the post-save read-back goes through the table's query so pivot/joined columns keep their value. This unlocks admin/back-office features (restore-and-edit, order lines joined to products) that were previously broken-by-default.
• Livewire-native UX is now viable. Re-renders no longer destroy an open cell editor, and a save response no longer wipes unrelated client-side errors. This supports polling, reactive filters, and multi-user dashboards without the editor "jumping."
• Roadmap signal: one open product question to own. The release explicitly notes a pending owner decision — the server cannot distinguish 1.250 typed by a user from 1.250 the grid holds, so it accepts it for number() columns. This is a product call (strict-reject vs. lenient-coerce vs. prompt-for-confirmation), not an engineering one. Put it on the roadmap before you market precision handling.
• Low migration cost to adopt. This is a patch on a 1.0 line: dev-dependency bumps only (jsdom 30, esbuild 0.28), built assets unchanged, no breaking API changes. Upgrading is a low-risk decision you can make in a sprint rather than a quarter.

When to Consider This Package

Consider it when:

• Your product needs inline, spreadsheet-like editing inside a Laravel/Livewire admin or internal tool, and users will paste from Excel or fill ranges.
• Data accuracy is user-visible — prices, quantities, SKUs, booleans, dates — and silent coercion would be a real defect rather than a cosmetic one.
• You already run Livewire and want editing that survives re-renders, polling, and filter changes without custom morph guards.
• You need server-side rule validation (unique, exists) to behave identically to Laravel's own validation semantics.
• Your tables sit on soft-deletable or pivot/joined models and you need save-after-restore and correct read-back.

Look elsewhere or wait when:

• You need a fully server-authoritative editing model. The acknowledged ambiguity between typed text and grid-held text means the server still trusts the client's number() payload in at least one path — if your threat model or compliance regime requires the server to re-derive meaning from raw input, this is an open gap.
• You are pre-1.0-averse: this is early 1.x, and the patch notes show a high density of state-management fixes (dirty tracking, copy/paste provenance, editor lifecycle). Expect a few more of these.
• Your grid needs features outside scope: formula evaluation, multi-sheet references, undo across sessions, or collaborative cursors.
• You are not on Livewire, or you need a non-Blade front end (Vue/React grid libraries would be a better fit).
• Heavy customization of cell internals is expected — the fixes here are tightly coupled to how the package owns cell state, and forking that behavior is costly.

How to Pitch It (Stakeholders)

To executives: This is a patch release on our grid-editing component that eliminates several ways bad data could silently enter the system — an ambiguous 1.250 used to become 1.25 (a 1000× error), unknown boolean words became false, and re-pasting an invalid cell could launder it into a valid value. It also fixes false "saved" confirmations when a model event cancels a save. Net effect: fewer data-quality incidents and fewer support tickets, at the cost of a dependency-only upgrade with no interface changes.

To engineering: No breaking changes; dev-dependency bumps only, built assets are byte-identical. The substance is correctness: invalid cells stay dirty and are never transmitted; dirty/copy provenance is tracked per source cell so a valid 1.234 beside an invalid cell holding the same text still pastes in machine form; Livewire morphs no longer nuke the open editor; required() rejects whitespace on both tiers; user rules are validated under the column name so unique:/exists: strings work; read-back goes through the table query so pivot/joined columns survive; save-cancelled-by-saving-event is surfaced as failure. The one thing we did not close is server-side disambiguation of user-typed vs. grid-held ambiguous text for number() columns — flagged as owner decision pending.

To the owner of that open decision: We need a stance before we advertise precision handling. Options are (a) strict-reject any raw text that isn't machine-parseable, (b) accept and coerce with an explicit user-facing confirmation, or (c) accept as today and document the limitation. Option (a) is safest for regulated or financial data; (c) is cheapest and defensible for internal tools where the client is the only writer.