Filament Modal Repeater Laravel Package

Technical Evaluation

Architecture fit. The component is a presentation-layer swap for Filament's native Repeater: same schema() array, same JSON-column or relationship storage, same action API. It introduces no persistence of its own — no tables, no migrations, no service provider state beyond an optional panel plugin. For a TPM this is the ideal dependency shape: it changes how a form is rendered, not what is stored, so a revert is a single line of code rather than a data migration. It sits cleanly in the Filament form-builder layer and inherits Filament's validation, save/dehydrate, and relationship handling rather than reimplementing them.

Integration feasibility. Low effort, well within a single sprint. Two dependencies (ModalRepeater, Column), one composer require, one artisan install command, an optional plugin registration. The README's usage block is effectively the entire API surface; a developer fluent in Filament can produce a working swap in under a day, and subsequent forms in hours. The schema() you already wrote is reused verbatim inside the modal, so incremental cost per additional form is close to zero.

Technical risk. The dominant risk is not code quality but maintenance concentration and version coupling. 18 stars and 0 dependents means near-zero downstream validation: we would be among the first production users, and regressions surface to us first. The changelog already evidences this — v1.1.3 fixed a fatal class-load failure caused by Filament 4.14/5.8 widening Component::schema()'s signature, and v1.1.1 fixed relationship binding and dot-notation column resolution. A fast-moving upstream (Filament ships frequently) plus a single maintainer is the classic profile of a component that breaks on upgrade rather than on use. Secondary risk: no documented behaviour for large item counts (pagination, lazy modal rendering) and no accessibility/validation-error documentation for the modal context.

Key questions.

• Which exact Filament major/minor and patch are we on, and does our composer.json allow minors to float?
• Do any target forms use custom repeater internals (mutateRelationshipDataBeforeSave, itemLabel, collapsed state, nested repeaters) that this subclass may not faithfully carry over?
• Does the install command publish config/assets, and what does it write into the repo?
• How are server-side validation errors surfaced inside the modal, and does focus management/accessibility hold up for keyboard users?
• What is the revert owner and trigger — do we have a standing rule to fall back to Repeater if a Filament upgrade breaks it?
• Is the 2026-10-05 release date genuine (freshness signal) or a metadata artifact we should discount?

Integration Approach

Stack fit. Requires PHP 8.2+, Filament v4 or v5; CI covers PHP 8.3/8.4 × Laravel 12/13. That aligns with a modern Laravel/Filament panel. Pin >=1.1.3 — every earlier release fails to load on Filament 4.14+/5.8+, which is a hard page failure, not a degraded render.

Migration path. Component-level, not architectural: replace Repeater::make('items') with ModalRepeater::make('items'), keep the existing schema() array untouched, add tableColumns() for the summary view. Roll out per-form behind a feature flag or on a single panel first. Revert path is the inverse substitution with no data implications — worth stating explicitly in the ticket so reviewers see the blast radius is one commit.

Compatibility. Constrain both sides of the contract: pin the package to a known-good ^1.1.x and pin Filament to a tested minor range with a committed lockfile. Treat any Filament minor bump as a change requiring a smoke test of every ModalRepeater form. Relationship-bound repeaters (address books, line items, child records) are the higher-risk surface given the v1.1.1 fixes; sequence them after array-backed repeaters are proven.

Sequencing.

1. One-day spike: convert a single internal, low-traffic admin form; verify save, delete, reorder, clone, and validation errors in the modal.
2. UX review with the form's owner on which fields belong in tableColumns() — the summary table is a product decision, not a technical one; if users routinely open a row just to read a value, that value belongs in the table.
3. Pilot on one production form with a known complaint (form too long, cluttered inline editing).
4. Measure: modal opens per session, form completion time, admin support tickets on that form.
5. Broaden to additional forms, then evaluate relationship-bound repeaters.
6. Defer reorderable/cloneable/extra-item-actions to follow-up tickets — they are one-liners on the inherited API and should not gate the initial rollout.

Fallback option. If adoption widens beyond a handful of forms and the maintainer goes quiet, fork under our namespace. The package is MIT and small enough (runtime archive ~16 KB as of v1.1.2) that owning it is realistic; decide the fork threshold up front rather than after an outage.

Operational Impact

Maintenance. Low ongoing code burden, but not zero: assume a few hours per Filament upgrade cycle for smoke testing, and a real possibility of emergency patching if Filament changes a method signature the subclass overrides. That is a recurring, predictable cost — budget it against the upgrade cadence rather than treating it as incident risk. If we fork, add dependency-update automation for the forked copy.

Support. The user-facing behaviour change is the cost centre, not the code. Users move from "everything visible inline" to "scan a table, open a modal to edit" — that is a learnable but non-obvious interaction. Mitigate with a deliberate emptyLabel(), clear add-action labelling, and a short note in admin onboarding. Expect a transient shift in tickets from "the form is too long" to "I can't find field X"; the answer is almost always a missing tableColumns() entry.

Scaling. No data-layer scaling concerns — it is rendering only. Watch form-level scaling: item counts in the hundreds, whether the summary table paginates, and whether each modal open re-renders a heavy schema. Verify with a seeded large dataset during the spike; this is undocumented and should be treated as unknown until tested.

Failure modes.

• Hard class-load failure on a Filament minor upgrade (v1.1.3 precedent) — the entire form page 500s. Highest-severity, most likely failure; detect via post-upgrade smoke test.
• Relationship mis-binding — silent wrong-record writes or a LogicException on pivot relations (v1.1.1 precedent). Detect via save-path tests on relationship repeaters specifically.
• Dot-notation column reads against array state instead of the related model — displays wrong or blank summary data while saving correctly. Cosmetic but erodes trust.
• Abandonment — no patches for the next Filament break; mitigated by the fork decision above.
• Modal validation UX — server-side errors landing inside a dialog without focus management; verify keyboard and screen-reader behaviour before rolling out broadly.

Ramp-up. Near-zero for developers already fluent with Filament's Repeater; the README plus one converted form is sufficient onboarding. The real learning curve is the inherited action API (editAction, extraItemActions, reorderable), which is Filament knowledge, not package knowledge. Document one internal reference implementation — a converted form with a non-trivial tableColumns() — and point new contributors at it instead of the upstream README.