Laradumps Filament Laravel Package

Getting Started

andrefelipe18/laradumps-filament bridges LaraDumps into Filament so you can inspect form/table state from inside the panel without dd(), ray(), or a browser tab full of dump() output.

Minimal setup:

composer require --dev andrefelipe18/laradumps-filament

You still need the LaraDumps desktop app and the base laradumps/laradumps package installed — the Filament adapter only supplies the Filament-specific glue. Confirm the package's service provider is auto-discovered (check composer.json → extra.laravel.providers in vendor/andrefelipe18/laradumps-filament), and publish any config if the README lists a tag:

php artisan vendor:publish --tag="laradumps-filament-config"

Where to look first:

1. README.md — the canonical list of macros/attributes and their signatures.
2. src/ — look for the service provider (macro registration) and, as of v1.4.0, src/Attributes/DumpFormState.php. Copy the exact namespace from the use statement rather than guessing.
3. The LaraDumps app itself — start it before your first request or you'll see nothing and assume the package is broken.

First use case — start with a single noisy form rather than wiring it everywhere. Annotate the component that owns your form schema:

use Andrefelipe18\LaraDumpsFilament\Attributes\DumpFormState; // verify namespace in vendor/

#[DumpFormState]
class EditPost extends ResourcePage
{
    // ...
}

Then load the page, change a field, and watch the form state object appear in LaraDumps. That single experiment tells you the attribute's granularity (class-level vs. method-level) and payload shape faster than any doc.

Implementation Patterns

Attribute-driven state logging (v1.4.0+). DumpFormState is declarative: instead of hand-placing ds($this->form->getState()) inside every updated() hook, you tag the component and let the package emit the state. This is the lowest-friction pattern for debugging a form you don't own end-to-end — drop the attribute on, reproduce the bug, remove it.

Macro chaining for spot checks. The package's value in day-to-day work is usually the fluent macros on Filament components. Typical shape:

TextInput::make('slug')
    ->live(onBlur: true)
    ->laradumps()          // confirm exact macro name in the README

Use this to confirm a field's afterStateUpdated payload, closures, or formatStateUsing output without breaking the request with dd().

Live + attribute, deliberately. DumpFormState only produces interesting output when state actually changes. Pair it with ->live() on the fields you care about, and keep debounce(500) on text inputs so you're reading a signal, not a keystroke firehose.

Repeater / Builder / Wizard debugging. These are the components where Filament state is hardest to reason about — nested arrays keyed by UUIDs and step indexes. The highest-ROI pattern is: apply the attribute (or the macro) only while actively debugging a repeater's ->relationship() save, then remove it. Do not leave it on a wizard used by the team.

Gate it by environment. Wrap usage so it never survives into shared environments:

// in a base page class or a trait
protected function shouldDumpState(): bool
{
    return app()->isLocal() && config('laradumps.enabled');
}

Or simply keep the package in require-dev and never deploy it — the cleanest guard is one that doesn't depend on config correctness.

Complement, don't replace, LaraDumps core. For anything that isn't form state (queries, HTTP, jobs triggered from an action), use the base ds() helper. Treat this package as the Filament-shaped entry point into the same app.

Gotchas and Tips

• Silent no-ops are the #1 confusion. If the LaraDumps desktop app isn't running, dumps go nowhere and no exception is thrown. Before debugging the package, verify a plain ds('hello') from a route works.
• Attribute scope is not obvious. DumpFormState may only fire on components that own a Filament form ($this->form); applying it to a table-only page or a plain Livewire component will likely produce nothing. Read the attribute's target (Attribute::TARGET_CLASS vs TARGET_METHOD) in src/Attributes/ — that tells you exactly where it's legal.
• Version coupling. Filament v3 vs v4 form-state internals differ. Pin the package version alongside your Filament major and check the composer.json constraints before upgrading either.
• Dump storms on ->live() fields. The attribute reads whole-form state, so a single keystroke on a live field dumps the entire schema. On large forms this can lag the panel. Use debounce()/onBlur or narrow the fields you mark live.
• Don't trust the payload for lazy/relationship fields. State for Select::make()->relationship() and repeaters with saveRelationshipsUsing can look empty or stale mid-request; dump again inside afterStateUpdated or afterCreate to see the settled value.
• Config and Octane caching. If you change package config, php artisan config:clear. Under Octane, restart workers — dumped state captured in a booted singleton will be stale.
• Production risk. Attributes are easy to forget and hard to grep for if you rename imports. Add a pre-deploy grep -r "DumpFormState" app/ check, or keep the package out of require entirely.
• Extension point worth knowing: if DumpFormState doesn't cover a case (e.g. table filters, action arguments), you're better off writing a small panel plugin or a macro of your own than forking — the underlying ds() API is stable and does the heavy lifting. Watch the repo's PR history (v1.4.0 was a single-feature PR) — this package moves in small increments, so pinning is cheap and upgrading is low-drama.