Drop In Action Laravel Package

Getting Started

Gate on the Filament major version before anything else. awcodes/drop-in-action is a Filament v2 form component. It predates the v3 reorganization of actions into Filament\Actions, and native Filament\Forms\Components\Actions supersedes it in v3+. Check before you commit:

composer show filament/forms | grep -i versions

On v3/v4, stop. Use native actions.

Reconcile the description against the source. The registry blurb ("register actions from a service provider, keeps resources clean, package-contributed UI actions") does not match the released code. The 0.2.x package is a single form-schema component that renders a row of Filament actions inside a form. There is no service-provider registration surface, no publishable config, and no Blade drop-in for non-Filament views. Open vendor/awcodes/drop-in-action/src/ and vendor/awcodes/drop-in-action/resources/views/ and confirm the FQCN and the filament/forms constraint yourself — the package ships no docs beyond a changelog.

Install pinned to the exact tag. This is 0.x; semver permits breaking changes in minor bumps, so ^0.2 is a trap on the next composer update:

composer require awcodes/drop-in-action:0.2.2

First use case — keep it boring and internal. Pick one admin screen where the form is the unit of work and a secondary action belongs next to a field. "Send test" beside a template/recipient field, or "Apply template" beside a body field — cases where navigating away would discard input.

use Awcodes\DropInAction\...\DropInAction; // verify FQCN against src/
use Filament\Forms\Components\Actions\Action;

->schema([
    TextInput::make('subject'),
    Textarea::make('body'),

    DropInAction::make()
        ->actions([
            Action::make('sendTest')
                ->label('Send test')
                ->icon('heroicon-o-paper-airplane')
                ->color('secondary')
                ->requiresConfirmation()
                ->action(fn () => app(TestMailer::class)->send(...)),
        ]),
])

If that renders and the action fires without disturbing the surrounding fields, the package's only real job is validated. Do this before building anything on top.

Implementation Patterns

Wrap it once and call the wrapper from every schema. With 0.x versioning and zero dependents, you want a single seam you control:

// app/Filament/Components/InlineActions.php
final class InlineActions
{
    public static function make(): DropInAction
    {
        return DropInAction::make()->columnSpanFull();
    }
}

When you migrate to native v3 actions — or vendor the component — you edit one file instead of thirty schemas. Highest-leverage habit with this package.

Group related actions into a single slot. ->actions([...]) takes an array. Two or three related buttons beneath the field they act on reads better than three separate components and gives you one place to control visibility and layout.

Carry the full v2 Action API through the array — that is the actual leverage. Everything on Filament\Forms\Components\Actions\Action behaves normally inside it: confirmations, modal forms, notifications, closures receiving injected dependencies.

Action::make('archive')
    ->label('Archive…')
    ->requiresConfirmation()
    ->modalHeading('Archive record')
    ->modalDescription('This hides the record from the list.')
    ->form([
        Textarea::make('reason')->required(),
    ])
    ->action(function (array $data) use ($record) {
        $record->archive($data['reason']);
        Notification::make()->title('Archived')->success()->send();
    })
    ->visible(fn () => auth()->user()->can('archive', $record));

Note the split: visible() is presentation only; the handler must enforce authorization itself.

Use inlineLabel() for dense admin forms. That is the entire substance of v0.2.2 — the view switched to x-dynamic-component so ->inlineLabel() passes through to the button, making embedded actions read like neighbouring fields. If your design system doesn't require inline-labeled controls, v0.2.2 is not a reason to upgrade.

Lay it out deliberately. The component occupies a grid cell like any field. ->columnSpanFull() gives a footer-style action row; nesting inside a Section or Grid puts it in the same column as the field it operates on. This is layout, not package behaviour — but it's the difference between "integrated" and "bolted on."

Keep each action self-contained. The intended shape is an action operating on its own data — the record, a mailer, a service class — not reading the parent form's live, unsaved state. Prototype anything that genuinely needs surrounding form values before committing; that's the known sharp edge, not a safe assumption.

Test the page, not the component. Render the Filament form page in a Livewire test, assert the button renders or is absent per authorization, and unit-test the handler's dependencies in isolation. There are no first-class test helpers — you are the edge-case tester.

Gotchas and Tips

Filament v2 only, and this will not change. The 0.2.x line is the v2 line. A cosmetic 2023 PR landing shows the repo is still triaged, not that a v3 roadmap exists. Budget the migration as a deletion: DropInAction::make()->actions([...]) maps nearly one-to-one onto native v3 actions. The ticket reads "remove awcodes/drop-in-action, replace with native actions," not "port the component."

Pin the exact version (repeat, because it matters). 0.2.2, not ^0.2. A 0.x minor bump may break the API, and a routine composer update is a bad way to discover that.

Actions may not see unsaved parent form state. The single most important thing to validate in a spike. If your action needs $get('body') or current dirty state, build a throwaway form, type into it, fire the action, and check what actually arrives. If it isn't there, redesign the action or the screen — don't fight the component.

Modal-form-in-form is the failure mode. An action with ->form([...]) opens a nested form inside a Livewire-rendered page. Validation scoping, modal state across re-renders, and dirty host-form state interact awkwardly. When weirdness appears, simplify the modal schema first; patching the package is almost never the fix.

x-dynamic-component can collide with your theme. The v0.2.2 change resolves the action view dynamically. If you ship custom action view overrides or a heavily themed panel, verify they still resolve — this breaks silently, not loudly.

Authorization belongs in the handler, not in visible(). The package has no auth logic; it delegates to Filament's pipeline. Privileged mutations need a policy or Gate::authorize() check inside action().

Extension points are the Action API, not the package. There is nothing to extend. Resist subclassing DropInAction; the entire surface is "render these actions in a form." If you need different markup, own the markup — see the next point.

Consider vendoring instead of depending. Under 150 lines, MIT, one Blade view, zero dependents. Copying it into app/Filament/Components/ with attribution is roughly half a day including tests, gets you immediate PHP 8.3 / Laravel 11 compatibility fixes, and turns future removal into a one-line refactor. For a component this small, the buy-side savings are modest and the supply-chain commitment is real.

Do not adopt it for customer-facing or security-sensitive surfaces. Internal admin CRUD, back-office tooling, operations consoles — yes. Revenue-critical screens, or anything where a stale dependency could block a framework upgrade — no.

Agree the exit criterion up front. If the wrapper isn't in place within the first sprint, or the package blocks a Filament upgrade, replace it. The capability is small enough that owning it is cheaper than negotiating with an unmaintained 0.x dependency.