Accordion Laravel Package

Product Decisions This Supports

• Build vs. buy on a commodity UI primitive. Collapsible/accordion sections are a solved problem. This package replaces hand-rolled Alpine/Livewire toggle logic with a single MIT-licensed Filament layout component. Scope it honestly: we are consuming one UI primitive, not adopting a framework or a design system.

• Unblocking long-form usability work without a front-end sprint. The recurring roadmap item this serves is "our 40-field admin form is unusable" or "settings need progressive disclosure." With this package the work becomes a schema-level change — wrap these fields in an accordion — rather than a bespoke component build. That shifts effort from engineering to configuration and compresses the timeline from a sprint to an afternoon.

• Design-system consistency is the real story of the 3.0.2 release. The patch publishes documented CSS hooks: zeus-accordion-btn / zeus-accordion-btn-* for triggers and zeus-accordion-container / zeus-accordion-container-* for panels. Product-wise this converts a recurring cost ("we fork the vendor Blade view every time branding changes") into a one-time, isolated styling layer. Documented extension points are what determine whether a third-party dependency stays cheap over a two-year horizon or becomes permanent fork debt.

• Consolidation of divergent implementations. Teams typically end up with three slightly different hand-rolled toggles across settings, FAQs, and filter panels. This gives one shared implementation with one theming entry point — a maintainability win that shows up as reduced review surface and fewer UI inconsistencies, not as a user-visible feature.

• Dependency risk posture, framed before it is re-litigated. 11 stars, zero dependent packages, a single-vendor ecosystem (lara-zeus), and a thin adoption signal mean this is a dependency we plan to be able to remove, not one we plan to standardize on. That has a concrete product consequence: we route all usage through one internal wrapper and never reference the package's selectors outside a single stylesheet, so replacing it with native <details>/<summary> or an in-house Alpine toggle is an afternoon of work. Low exit cost is the actual buy decision.

• A usability assumption worth validating, not assuming. Collapsed sections are visual only — fields inside them remain mounted, validated, and submitted. That's good news for our validation rules and $fillable handling, but it means a required field hidden in a collapsed panel produces "the form won't submit and I can't see why." Product rule to commit to up front: collapse only optional or genuinely secondary fields, or open the section by default.

• Scope boundary worth naming explicitly. The package description markets "simple Blade integration" while the repository reality is a Filament schema component that tracks Filament's majors. These are different audiences and different support burdens. Before we build a roadmap around it, confirm which one it actually is — otherwise we plan for a Blade-only page and discover we've signed up for a Filament version-coupling commitment.

When to Consider This Package

Adopt when all of these are true:

• You are already inside a Filament panel and need collapse to cooperate with the form's state, layout, and theming. That integration value is the only reason to take on a third-party lifecycle here.
• Your Filament major version matches what the package targets (confirm before committing; it's on its third major line and follows Filament's). If you're behind on Filament, you're likely behind on this too — and the fix is an upgrade you weren't planning.
• The use case is secondary content: SEO/metadata blocks, advanced settings, publishing options, internal notes, action-modal forms where height is constrained.
• You are willing to put in place three cheap guardrails: pin the exact patch version rather than a caret range; funnel all construction through one internal wrapper (e.g. Fields::metaSection()); confine theming to one stylesheet using only the documented hooks.
• You have a testing habit: one functional test proving collapsed fields still save, plus one visual check covering collapsed and expanded states. A patch bump silently restyling a panel is invisible to a functional test — that is the realistic failure mode.

Look elsewhere, or don't adopt, when:

• It's a single collapsible FAQ block on a marketing page. Native <details>/<summary> is zero dependencies, keyboard-accessible by default, and works without JS. Taking on a maintenance lifecycle for one toggle is a bad trade.
• You need the collapse to be accessible out of the box and can't afford to own the ARIA work. The release notes say nothing about aria-expanded, aria-controls, or keyboard handling. Verify once, write down the answer, and assume it's ours to add — cheapest at the single wrapper, not nine call sites.
• You'd be nesting accordions inside accordions, or nesting them inside tabs inside sections. One level of collapse is the ceiling; if you want two, the real problem is too many fields and the answer is a tab or a wizard step.
• Your roadmap depends on this being actively maintained and supported. There's a single maintainer, no dependents, and a thin signal. Read that as "we can use it, we cannot rely on it" — and make sure nothing in the plan requires a vendor fix.
• You are not on Filament at all. This is not a general-purpose Blade accordion, whatever the description implies.

How to Pitch It (Stakeholders)

To executives — one paragraph. We can fix a recurring usability complaint — admin forms and settings screens that are too long to navigate — with a small, free, MIT-licensed UI component instead of a front-end build. The work becomes configuration rather than engineering, so we get the usability win in an afternoon rather than a sprint, and we consolidate three or four inconsistent toggle implementations into one. The dependency is deliberately small and, critically, cheap to reverse: because it exposes documented styling hooks and we're isolating every usage behind one internal wrapper, replacing it later is measured in hours. This is a low-cost, low-commitment improvement to internal tooling, not a platform decision.

To engineering — the summary. A Filament layout component for grouping schema fields into collapsible panels, currently on its 3.x line tracking Filament majors. Three things to internalize before you use it:

1. It's small and we treat it that way. Pin the exact patch. Route every usage through one wrapper (Fields::metaSection(...)) so heading copy, icons, and default open state live in one file. Never reference zeus-accordion-* selectors outside a single stylesheet, and never target the internal DOM — only the documented base classes from 3.0.2.
2. Know the two failure modes. Collapsed is not absent: fields inside a closed panel still validate and still submit, so a hidden required field yields an invisible blocker. And open/closed state is Alpine-driven, so test that a panel you opened doesn't snap shut after a live() field inside it updates. That exact combination is what breaks.
3. Read the source, don't trust the README. The Blade views under resources/views/ are the documentation. Confirm the component namespace and method names (->collapsed() vs ->open(false)) from src/ before writing call sites. If collapse breaks after an upgrade, diffing the vendor views is the entire changelog you need.

Start with one screen — a Resource form split into a "daily fields" top half and a collapsed "metadata" bottom half. Verify rendering, verify collapsed fields still save, verify the Livewire re-render behavior, check ARIA and keyboard handling once and record the result. Then widen adoption. And keep exit cheap: the realistic risk isn't a bug, it's abandonment — the guardrails above are what turn that from a sprint into an afternoon.