Drop In Action Laravel Package

Product Decisions This Supports

• Where secondary actions live in the UI. The package lets us render Filament actions — confirmation buttons, modal forms, workflow triggers — inside a form schema, next to the fields they act on, instead of only in table rows or page headers. That is a UX decision, not a styling detail: "Send test" beside a recipient field, "Apply template" beside a body field, "Archive with reason" on an edit screen.
• Keeping users in context. It makes viable the deliberate choice to let users act without navigating away or saving first. For back-office power users, this is a real completion-rate and support-ticket trade-off worth evaluating against the alternative (save, leave, come back, lose state).
• Build vs. buy on a small capability. The honest framing is three options at roughly comparable cost: adopt a one-component 0.x dependency (near-zero build cost, real maintenance risk), write ~150 lines in-house (about half a day plus tests, full control), or de-scope the interaction. Keeping the decision at this granularity avoids escalating a thin UI affordance into an architecture debate.
• A policy question on community plugins. With ~86 stars, zero dependents, and a 0.x line, this reads as a single-author utility. The May 2023 release (a first-time contributor's inline-label fix) shows the repo is still triaged, but one cosmetic PR is not evidence of sustained maintenance. This is a useful test case for whether we adopt community Filament plugins freely or require vendoring for anything we depend on.
• Design-system consistency in dense admin forms. v0.2.2's x-dynamic-component change lets ->inlineLabel() pass through, so an embedded action reads like a neighbouring field rather than a bolted-on control. Relevant only if our admin design system mandates inline-labeled controls — otherwise it is not a reason to adopt or upgrade.
• Roadmap signal, not a roadmap item. The package has no v3 story, and the correct migration is a deletion: DropInAction::make()->actions([...]) maps almost one-to-one onto native Filament v3 actions. So adopting it carries a scheduled removal cost we should book now, not discover later.
• Use cases to prioritize: internal admin CRUD, back-office and ops consoles, content/moderation workflows — any screen where the form is the unit of work and the action is scoped to that record.

When to Consider This Package

Adopt only when all of these hold:

• You are on Filament v2. This is a hard gate, not a preference. On v3+, native Filament\Forms\Components\Actions already covers this and the package targets an API surface that no longer exists.
• You need actions embedded inside a form, and native table/page action placement genuinely does not fit the workflow.
• You need inline-label styling so the embedded control matches adjacent fields (the specific v0.2.2 capability). Without that need, v0.2.2 is not itself a reason to adopt.
• The action is self-contained — it operates on the record or a service, not on the parent form's live, unsaved values. Any workflow depending on $get('body') must be validated in a spike first; this is the known sharp edge.
• The surface is internal and low-blast-radius, the team can absorb the component if the author walks away, and MIT licensing keeps the fork option open.
• Time-to-value beats a long-term support commitment for this specific screen.

Look elsewhere or build in-house when:

• You are on v3/v4 or plan to upgrade within the product's lifetime. A stale dependency on a fast-moving framework's internals is a migration tax, not a shortcut — and v0.2.2 touches the rendering path, exactly the kind of coupling that complicates upgrades.
• The screen is customer-facing, revenue-critical, or security-sensitive. The package has no auth logic of its own; it delegates to Filament's pipeline, so whatever risk exists is what we wrote — put policy checks in the action handler, never in visible().
• Workflows require the action to read surrounding unsaved form state, or rely on nested modal-forms-in-forms, which is the documented failure mode.
• You want a supported dependency with a maintenance commitment. Zero dependents and a 0.x version line mean no API stability guarantee — pin the exact tag (0.2.2, not ^0.2), because a routine composer update is a bad way to learn about a breaking minor bump.
• You would otherwise build on it broadly before validating it. Wrap it behind one internal seam (e.g. InlineActions::make()) so migration-to-native or vendoring is a one-file change rather than a sweep across thirty schemas.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed UI component that lets us place action buttons inside admin forms, so operators can complete multi-step back-office tasks without leaving the page or losing entered data. Cost to adopt is roughly zero; cost to own is roughly half a day if we copy it in-house. It is deliberately scoped to internal admin tooling — not customer-facing or revenue-critical surfaces — and it only works on Filament v2. If we are on v3, the framework already does this natively and we should not take the dependency at all. The recommended position: prototype it in one internal screen behind a single wrapper, with an agreed exit criterion — if the wrapper isn't in place within the first sprint, or it blocks a Filament upgrade, we replace it with native actions or our own copy.

For engineering: It is one form-schema component plus one Blade view, under ~150 lines, no config, no docs beyond a changelog. Read the source and confirm the FQCN and the filament/forms constraint yourself rather than trusting snippets. Pin 0.2.2 exactly. Validate two things in a spike before building: that an embedded action fires without disturbing surrounding fields, and whether it can see unsaved parent form state (assume it cannot). Authorization goes in the handler, not in visible(). Given the size, vendoring into app/Filament/Components/ with attribution is a defensible alternative to a Composer dependency — it buys us PHP 8.3/Laravel 11 compatibility fixes immediately and makes removal trivial. Either way, the eventual migration ticket should read "remove and replace with native v3 actions," not "port the component."