Hello Stimulus Bundle Laravel Package

Product Decisions This Supports

• Feature-level: Enables forms rendered by the package to carry a controller identifier as a data- attribute on the <form> tag, which materially affects how server-rendered forms integrate with client-side behavior (Stimulus/Stimulus-style controllers, Hotwire/Turbo, Alpine, or a custom JS layer). This is a small but meaningful DX feature for teams building interactive forms with a progressive-enhancement stack.
• Build vs. buy: For teams considering whether to adopt this package versus rolling their own form-view layer, the presence of first-class hooks for frontend-controller binding reduces the justification for a custom internal abstraction. Conversely, one helper method is not enough on its own to justify adoption; it is a supporting data point, not a deciding one.
• Roadmap signal: The package is at v0.2.0 and the first meaningful change adds an HTML attribute helper. This reads as early-stage, incremental development — expect API surface to keep moving. Plan for churn and pin versions if you depend on it.
• Use cases: Admin panels, internal tools, and CRUD-heavy Laravel apps where forms need to attach JS behaviors without hand-editing Blade templates; useful where multiple forms must be consistently tagged with controller names for a shared JS dispatcher.

When to Consider This Package

Consider adopting when:

• Your stack already uses client-side controller conventions (e.g., Stimulus/Hotwire) and you want the form-rendering layer to emit the bindings rather than repeating markup in each view.
• You want the controller identifier to be set programmatically from server-side context (e.g., derived from request/route/component) instead of hardcoded in templates.
• You are comfortable adopting pre-1.0 PHP packages with a thin public surface and are prepared to track releases.

Look elsewhere when:

• You need a mature, stable form library with a settled API; v0.2.0 with a one-line feature release does not evidence that.
• Your frontend integration is already handled by a full-fidelity form package (Laravel Collective, Livewire, Filament, Inertia forms) — this would duplicate concerns.
• You cannot tolerate a small, undocumented feature set — there is not yet enough surface here to justify migration cost.
• Your forms are static; the feature only pays off when forms need behavioral wiring in the browser.

Adoption guardrails: pin the version, confirm the attribute name/emission matches your JS framework's expected convention, and check that the method composes with existing attribute setters (no silent overwrite of other data-* attributes).

How to Pitch It (Stakeholders)

Executive summary: This release adds a small convenience for emitting a controller identifier onto form markup, improving how server-rendered forms wire up to frontend behavior. It is a developer-experience improvement, not a capability shift — low risk, low effort, no migration impact visible.

For engineering: v0.2.0 adds setControllerNameToFormView, which sets a controller data- attribute on the form tag. Adopt only if you already depend on this package or are standardizing form markup emission; verify attribute naming matches your JS controller convention and confirm no collision with other form attributes. Package remains pre-1.0 — pin versions, and treat the public API as unsettled until a 1.0 milestone.