oddvalue/filament-draft-recovery
Auto-save and crash recovery for Filament v4/v5 create and edit pages. Form state is saved as a debounced draft (2s by default), so users can recover unsaved work after a browser crash, tab close, or lost connection. Swappable storage drivers included.
Architecture fit. Unchanged. The package remains a Filament panel plugin living inside the admin surface our teams already own, hooking the create/edit page lifecycle and persisting form state to a swappable driver (localStorage, database table, or oddvalue/laravel-drafts). The driver abstraction is still the architecturally load-bearing piece: it lets us start with no server-side footprint and graduate to cross-device recovery without changing page code. One refinement from v1.0.0: draft clearing now runs through "trait-named lifecycle hooks," which means the clear-on-submit behaviour is an extension point rather than hardcoded. That is architecturally better (we can override per-resource), but it moves part of the contract into naming conventions we must document.
Integration feasibility. Still low-to-moderate, with one added step. Install is Composer plus plugin registration; the database driver adds a publishable migration and config. The v1.0.0 delta that matters is PR #13, which rewires how drafts are cleared on lifecycle events. That is a behavioural change in the exact path we care most about — clearing a draft after a successful submit. Treat the 0.5.x → 1.0.0 upgrade as needing an explicit regression test on that path, not a version bump. The rest of the release (README artwork, badge links, prose tightening, hiding a banner on the plugin page, Dependabot bumps) is housekeeping with no integration impact.
Technical risk. Maturity risk is partially, not materially, reduced. Reaching 1.0.0 is a real signal: the maintainer is asserting API stability and, by semver convention, will batch breaking changes into future majors rather than shipping them in minor releases. That is worth something for a package in the write path of every create/edit form. But 1.0.0 does not change the underlying exposure — a single maintainer, and the same maintainer owns oddvalue/laravel-drafts, so the "swappable driver" insurance is weaker than it looks: two of our three driver options depend on the same person. Dependabot activity shows a live CI/dependency pipeline, but automated bumps are not evidence of feature investment. Most tellingly, the 1.0 milestone shipped no encryption at rest, no tenancy/authorization scoping on draft rows, no TTL or prune command, and no documented conflict-resolution change. The hardening items we flagged pre-1.0 are still open at the stable release, which suggests we should assume they are roadmap-absent rather than roadmap-pending. Secondary risks are unchanged: silent autosave failure, stale-draft overwrite, localStorage quota exhaustion on large repeaters/rich text, PII in browser storage or an unmanaged table, and partial/no recovery on upload-heavy forms.
Key questions.
Stack fit. Unchanged. Requires Laravel with Filament and Livewire. localStorage is a pure front-end addition; database and laravel-drafts drivers introduce persistent state and therefore data-classification, retention, and backup review.
Migration path. Still additive, no data migration. Sequence: (1) pin to ^1.0 and read the 0.5.x → 1.0.0 diff around PR #13 before anything else; (2) install and register behind a config flag on a single non-critical panel; (3) validate on one representative resource with a complex form, explicitly testing save-then-verify-draft-cleared; (4) choose the driver based on whether cross-device recovery is a real requirement; (5) if database-backed, ship the migration through the normal schema pipeline with a retention job in the same change; (6) enable resource-by-resource.
Compatibility. Verify PHP and Filament constraints from composer.json and pin the major. Because draft clearing now uses trait-named hooks, check for collisions with any in-house traits on our resources — a same-named method on a resource trait is now a silent override surface. Confirm no clash with existing draft/versioning or audit packages claiming the same form lifecycle.
Sequencing. The driver choice remains the decision gate, and v1.0.0 adds a second gate: verify the lifecycle-hook clearing behaviour before promoting beyond a pilot. localStorage first still buys a two-week proof of value with a trivial rollback. Do not promote to the database driver until we have evidence of user reliance and an agreed retention policy; a 1.0 tag does not create that evidence.
Maintenance. Small surface and MIT licensing keep cost low, but ownership is concentrated — and now demonstrably spans two packages in our dependency graph. Plan for a credible fork; the scope is narrow enough that maintaining one is feasible, but a fork may need to cover both the plugin and the drafts package. Budget a review per Filament major, since page-lifecycle hooks are where churn lands. The 1.0 tag should reduce mid-cycle churn, which modestly lowers our review burden between majors.
Support. Support load remains user-driven: "my draft didn't come back," "it restored an old version," "it keeps prompting me." v1.0.0 adds a new one — "it didn't clear after I saved" — so the runbook should include the lifecycle-hook change and how to confirm a draft was actually cleared. With effectively no downstream dependents, we are still the first line of support.
Scaling. Unchanged. localStorage scales for free but is per-browser and capped near 5 MB per origin. The database driver converts autosave into write traffic proportional to editor-minutes × debounce rate; size it against peak admin concurrency and prefer it only where the recovery guarantee justifies the load.
Failure modes. Silent autosave failure with no user signal; stale draft overwriting fresher server data; drafts not cleared after a successful submit (now a named change surface post-PR #13); orphaned rows accumulating without TTL; PII in localStorage on shared machines; a recovery prompt appearing after a successful save. Each needs an explicit mitigation — visible "saved at" indicator, server-side conflict check, scheduled prune, and a policy excluding sensitive resources from browser storage. The 1.0.0 release notes give no indication any of these have been addressed in-product, so the mitigations remain ours to build or accept.
Ramp-up. Unchanged for the code — hours to a working install, one to two days to a defensible pilot. The PR #13 hook change adds perhaps an hour of reading for whoever owns the pilot, so they can explain to reviewers why drafts clear the way they do. The real learning curve is still agreeing what "recovery" means for our users and who owns the drafts afterwards.
How can I help you explore Laravel packages today?