Filament Choosable Chips Laravel Package

Product Decisions This Supports

• Form UX density in admin/back-office surfaces. Chips are a meaningful middle ground between a native Select (compact but hides options behind a click) and CheckboxList/Radio (fully visible but vertically expensive). This supports decisions like "can we expose 6–12 enum-backed options — status, tags, channels, roles — without a multi-row layout that pushes the primary action below the fold?"
• Feature-level build vs. buy for Filament form fields. Rough scope of a hand-rolled equivalent: a custom Field class, state casting for single vs. multiple, per-option color/icon/description resolution, Blade view + Alpine interactivity for dismiss/check states, enum bridging, and derived validation. Realistically 1–3 engineering days plus ongoing maintenance against Filament major versions. At composer require cost, the buy side wins if the dependency risk is acceptable (see below).
• Roadmap sequencing for admin-panel polish. This is a "cheap wins" item — high perceived quality per unit of effort — which makes it a good filler for a sprint where the team is blocked on backend work, rather than something that justifies its own initiative.
• Consistency standardisation across an application. If you have N resources each rendering option sets differently (some Select, some ToggleButtons, some CheckboxList), adopting one field is a concrete, low-risk way to execute a "consistent admin UI" decision without a design-system project.
• Validation and data-integrity posture. The in rule derived from enabled options matters more than it looks: it means "disabled option" and "invalid submission" stay in sync automatically, which is a decision to not hand-maintain allowed-value lists per form.
• Not supported: anything public-facing or customer-branded. This is a Filament admin-panel component; it does not inform storefront or end-user product decisions.

When to Consider This Package

Consider it when:

• You are on Filament v5 and PHP 8.4+. Both are hard requirements; the PHP floor is the more likely blocker — teams commonly sit on 8.2/8.3, and PHP 8.4 is recent enough that "we can't upgrade yet" is a realistic answer. If you're not already there, this package is not a decision you can make today.
• The form field in question has a bounded, enumerable option set (roughly 3–15 values) that users benefit from seeing all at once — status filters, categories, tag selection, notification channels, scopes/permissions.
• Options carry semantic weight beyond their label: colors for severity, icons for type, descriptions for consequences. That's exactly the per-option metadata API this exposes, and it's where the value concentrates.
• You want single/multi select parity across screens — the ->multiple() toggle means the same primitive covers radio-like and checkbox-like cases, which reduces the number of distinct components your team must learn.
• Enum-backed state is your norm; first-class enum support removes glue code.

Look elsewhere when:

• PHP < 8.4 or Filament v4/v3. No fallback path is offered. Don't plan around a backport.
• The option set is large or unbounded (20+ values, searchable/lookup-driven). Chips don't scale; use a searchable Select or relationship field.
• Dismissable chips are the headline and your form is a create form. Dismissal is a nice affordance for "remove this filter/tag," but on a first-entry form it can read as destructive or accidental. Be deliberate about where you enable it — and note the package's own quirk that the selected check mark replaces the dismiss button, so you cannot have both simultaneously.
• Dependency risk tolerance is low. v1.0.0, single-vendor (VitisStudio), no release history, no stated support policy. For a component that lives inside your admin panel — low blast radius, but also low switching cost — this is usually acceptable; for a regulated or long-lived product, vendor a fork or budget the 1–3 days to build in-house.
• Accessibility is a hard gate. Chip/badge interaction patterns with a delete button layered on a selectable control need keyboard and screen-reader verification. The release notes say nothing about ARIA, focus management, or keyboard semantics. Treat this as unverified until you test it, not as a feature.
• You need granular control over layout beyond gridDirection()/size(), or a custom chip renderer.

Adoption recommendation: pilot in one non-critical resource behind normal code review; verify keyboard/screen-reader behaviour and the single↔multi state cast before rolling out broadly. Pin the version — pre-1.x stability guarantees are not something a v1.0.0 release establishes on its own.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source UI component for our admin panel that makes option pickers — statuses, tags, categories — more compact and more legible, with colour and icon cues that reduce mis-selection and support tickets from internal users. It is not customer-facing and carries no licensing cost or contractual commitment. The effort to adopt is measured in hours, not weeks, against an estimated 1–3 engineering days to build and maintain an equivalent ourselves. The main caveat is that it requires a newer PHP version (8.4+) and the latest Filament release, and it is a brand-new package from a single publisher — so it's a low-risk, easily reversible bet, best trialled on one screen before wider use. Think of it as admin-experience polish we can bank cheaply, not a strategic investment.

For engineering (summary): A Filament v5 form field rendering options as dismissable, colour/icon-bearing chips, with a fluent API mirroring Select/ToggleButtons. Covers single and multiple selection with correct scalar/array state casting, per-option colors()/icons()/descriptions(), disableOptionWhen(), checkSelected() with configurable selectedColor()/checkIcon(), size(), defaultColor(), gridDirection(), enum support, and an in rule derived from enabled options. Two constraints to plan around: PHP 8.4+ and filament/forms ^5.0 are both hard floors, and there is no documented fallback. Two behaviours to know before wiring it up: checkSelected() auto-enables when no per-option icons are set, and the check mark replaces the dismiss button while shown — you can't have both. Open questions we should answer in the spike: keyboard/screen-reader semantics for a selectable badge with a delete affordance, and whether the derived in rule composes correctly with our own validation. Pin to v1.0.0; single-vendor package with no support policy, but the surface area is small and forking is cheap if it goes quiet.