Forms Laravel Package

Product Decisions This Supports

• Ship compact, conversion-oriented forms without custom CSS. The new layout: 'inline' option on FormRenderer makes the canonical high-intent pattern — one email field plus a Subscribe button on a single line — a supported, first-class configuration rather than a bespoke stylesheet every team rewrites. This directly de-risks newsletter capture, waitlist signups, and inline CTA blocks in marketing pages and landing templates.
• Design-system consolidation and build-vs-buy. submitClassName (applied in both layouts) lets a host application pass its own design tokens — e.g. wp-element-button in a WordPress-adjacent stack, or an internal btn btn-primary primitive — instead of fighting package defaults. This is the deciding argument when the alternative is either (a) building a form renderer in-house to get button-level styling control, or (b) adopting the package and then shipping a CSS override layer you have to maintain forever.
• Roadmap sequencing for design-system migrations. Because submitClassName is additive and the default stacked output is explicitly unchanged, adopting v1.5.2 is safe to slot into an in-flight design-system migration without a freeze on form work. You can adopt the hook now and defer the visual migration.
• Reduced frontend scope in Laravel-first teams. The PHP-side package plus React/Vue renderers means a Laravel team can offer a polished, design-system-conformant form UI without a dedicated frontend build. That affects headcount planning and whether form UX becomes a roadmap item or a solved dependency.
• Explicit non-goal you can plan around. Multi-step forms ignore layout. If your roadmap includes wizard-style onboarding or checkout flows, do not assume this release moves that needle; keep multi-step UX scoped separately.
• Type-safety for TypeScript consumers. The new FormLayout type export and matching layout prop on FieldRenderer mean typed wrappers and internal component libraries can pass layout through without any casts — a small but real velocity and correctness gain for teams with a shared component layer.

When to Consider This Package

Consider adopting when:

• You are on Laravel/PHP and want a forms package whose rendering layer already speaks React and Vue, avoiding a second UI stack.
• Your forms are predominantly simple, single-page captures (newsletter, contact, lead gen, feedback) where layout: 'inline' or the default stacked covers the requirement outright.
• You need the submit control to conform to an existing design system and are unwilling to own a forked renderer — submitClassName is the pressure valve here.
• You are on TypeScript and want layout configuration to be a typed contract rather than a stringly-typed prop.
• You want a low-risk, additive upgrade path: v1.5.2 changes no default output, so adopting it is not gated on a visual regression pass.

Look elsewhere, or supplement, when:

• Multi-step / wizard flows are central. layout is explicitly ignored there; this release adds nothing to that surface, and you should not let a form-package decision be justified by multi-step needs it does not serve.
• You need deep, per-field layout control (grid spans, side-by-side field groups beyond the single inline row). inline is a one-row, button-shares-the-row primitive with a 12rem field minimum and wrap behavior — deliberately narrow. Complex responsive form composition still argues for a dedicated builder or bespoke components.
• Your stack is not React or Vue (Svelte, server-rendered Blade-only, native). The headline capabilities in this release are renderer-level.
• You require guaranteed non-wrap behavior in very narrow containers. The documented wrap-below behavior is a sensible default but is a visual outcome you must design and test around, not a constraint you can configure away.
• You need a formal accessibility conformance statement. Nothing in these notes addresses it; treat that as an open, separate evaluation.

How to Pitch It (Stakeholders)

For executives: This is a low-risk, additive release to a package we already depend on for form rendering. It removes a recurring source of custom frontend work — every team hand-styling a one-line email-plus-button signup — and lets forms inherit our design system's button styles through a single supported prop instead of a maintained CSS override layer. There are no breaking changes: the default rendered output is unchanged, so there is no migration cost and no regression risk to existing pages. The business value is faster shipping of conversion-oriented signup surfaces and less bespoke frontend maintenance.

For engineering leads: v1.5.2 is non-breaking and additive. FormRenderer (React and Vue) gains two optional props — layout: 'stacked' | 'inline' defaulting to 'stacked', and submitClassName appended to the submit button in both layouts. layout: 'inline' places the submit button as the last item in the field row, bottom-aligned, non-growing, without its own wrapper <div>; full-width fields clamp to a 12rem minimum capped at row width so narrow rows wrap rather than overflow. Multi-step forms ignore layout entirely. TypeScript consumers get a new FormLayout type and a matching layout prop on FieldRenderer. Recommendation: adopt now to unblock design-system button integration and retire local override CSS; keep multi-step form work scoped separately, since this release does not touch it. Validate inline wrapping behavior at your narrowest supported breakpoint before standardizing on it in shared templates.