Fluid Actions Laravel Package

Product Decisions This Supports

• Build vs. buy for admin UX polish. Fluid Actions is a thin, additive layer over Filament's existing Action API. It answers a narrow but recurring product question — how much deliberate friction should a destructive action have? — without requiring a bespoke component. The realistic alternative is one to three days of in-house work reproducing inline confirmation; adopting the package shifts that to a Composer line and a plugin registration.
• Choosing the friction model per action. The package exposes a spectrum rather than a single pattern: lightweight inline confirmation for reversible/low-cost actions, hold-to-confirm for irreversible or high-blast-radius ones (deletes, refunds, deactivations, bulk operations), and Filament's native modal as a fallback for complex flows. That lets you make a per-action product judgment instead of picking one global confirmation style for the whole admin.
• Roadmap input for the internal admin experience theme. If "operators make avoidable destructive mistakes" or "admin feels utilitarian" shows up in support tickets or in sales demos, this is a low-cost, low-commitment way to test whether interaction polish moves the metric before funding a larger design-system effort.
• Use cases worth scoping: destructive row actions in resource tables, state transitions (approve/reject/deactivate), actions nested in dropdown/grouped menus where a full modal feels heavy, and rapid repetitive operator workflows where modal round-trips cost real time.
• Risk-surface decision. 12 stars, zero dependents, and a single maintainer mean this is a tactical dependency, not a platform bet. Under MIT you can vendor the ~small surface into your codebase, which converts the adoption decision from "do we trust this maintainer for three years" into "do we want this UX next sprint."

When to Consider This Package

Consider it when all of the following hold:

• You are already on Filament and Actions are the primary interaction primitive in your admin panel.
• Your users are operational staff (support, ops, finance) whose misclicks have real cost — refunds, deletions, account state changes — and a wire:confirm browser dialog feels off-brand or too blunt.
• The UX gap is friction calibration, not missing functionality — you don't need new capabilities, just better-shaped ones.
• You can pin an exact version and are comfortable vendoring or forking a small MIT package if the maintainer goes quiet. Treat this as source you're adopting, not a vendor you're relying on.
• You want to validate the interaction pattern cheaply before committing design and engineering time to an in-house component library.

Look elsewhere — or build it yourself — when:

• You're not on Filament. The entire value is integration with its Action lifecycle; outside that it's a few Alpine/Blade interaction patterns you'd reimplement anyway.
• You need accessibility or compliance guarantees. No evidence of WCAG testing, keyboard-navigation guarantees, or audit logging. Hold-to-confirm in particular is a pattern that can fail keyboard and assistive-tech users; verify before shipping it against a destructive action.
• You need vendor-backed support or a security review process. A pre-1.0-adoption, single-maintainer package with no dependents won't clear a procurement or third-party-risk gate.
• Your confirmation needs are genuinely complex. Multi-step wizards, typed confirmation strings, reason capture, or approval chains are better served by Filament's native modal plus a form — and this package's "smart fallback" already assumes you'll use it there.
• The interaction is not worth the abstraction. For one or two actions, a native modal is fine and adds zero dependency.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT), additive UX upgrade for our admin panel that reduces accidental destructive actions — the kind that generate support tickets and occasionally require incident review. Cost is a dependency line and roughly an hour of integration; the changes are opt-in per action, so if it doesn't earn its place we remove the plugin and every action reverts to standard behavior. The honest caveat is maturity: it's a young, low-adoption package from a single maintainer, which is why I'd recommend pinning the version and vendoring the source rather than treating it as a long-term vendor commitment.

To engineering: A Filament plugin that swaps the confirmation mechanism on selected Actions — inline confirm, press-and-hold, and group/dropdown support — with per-action configuration for hold duration and timeout, plus automatic fallback to Filament's default for anything complex. Integration is composer require plus one ->plugin() registration, and adoption is incremental per action, so blast radius is small and rollback is deleting one line. Two conditions before we merge: pin the exact version and vendor or fork the source, and confirm keyboard/assistive-tech behavior on hold-to-confirm before we attach it to anything irreversible. If either condition is unmet, we're one to three days from building the inline-confirm variant ourselves — that's our BATNA and it should cap how much we invest here.