Flowforge Laravel Package

Product Decisions This Supports

• Roadmap: ship board UX without building it. Group-by menu, sticky lane labels, and collapsible lanes are table-stakes for "Modern" kanban views; adopting v4.3.0 lets you close those roadmap items by upgrading a dependency rather than funding a multi-sprint front-end build.
• Build vs. buy/integrate. The release concentrates on hard, low-differentiation problems — drag-vs-click gesture disambiguation, lane virtualization of card payloads, sticky positioning. Internal effort is better spent on domain logic (workflows, permissions, automation) than on pointer-event heuristics.
• Performance budget as a product requirement. A flat 125-card Modern board drops from 2.6 MB to 1.0 MB of HTML. That is a ~60% reduction in what the browser parses before first paint — it directly supports decisions about maximum cards-per-board, mobile/low-bandwidth support, and whether boards are usable on mid-tier devices.
• Interaction quality bar for card actions. A click that drifts a few pixels now opens the card action instead of starting a drag. This supports a product decision to put destructive or modal-triggering actions on cards, and reduces the "I tried to open it and it just wiggled" support class of tickets, especially on trackpads and touch.
• Segmented rollout by board type. Classic boards are unchanged, so you can enable Modern boards for new tenants/workspaces and keep Classic for legacy or high-touch accounts — a low-risk migration path rather than a flag-day cutover.
• Feature parity vs. differentiation. Treat board rendering as commodity and differentiate elsewhere; conversely, if the board is the product surface, this release is evidence the vendor is still investing.

When to Consider This Package

Adopt when:

• Your stack is Laravel with Livewire/Alpine, and you want a board rendered server-side into your existing Blade/Alpine app rather than a separate SPA.
• Your board needs are recognizably kanban: lanes, drag-and-drop cards, custom card content, grouping and collapsing of lanes.
• You have limited front-end bandwidth and no appetite to own drag-and-drop gesture code, sticky layout, and HTML payload tuning in-house.
• You can consume a component whose front-end internals are explicitly not a stable contract — see the v4.3.0 note that $data.state read from your own Alpine code on a Modern board is gone. Your integration should hang off documented APIs, slots, and events, not internal Alpine objects.
• Board sizes are in the tens-to-low-hundreds of cards per board; 1.0 MB for 125 cards is a workable ceiling, not headroom for thousands.

Look elsewhere when:

• You need a formal public API/DOM stability guarantee. The $data.state removal is described as never having been part of the design contract; if your app embeds Alpine logic tightly into the board, expect this class of breakage on minor releases.
• Your boards are very large or real-time-multiplayer: even the reduced payload is substantial, and per-card data still ships in the page. A virtualized client or paginated API may be a better fit.
• You are not on Laravel/Livewire, or you need a headless board engine with a custom renderer.
• You need deterministic, versioned theming hooks and a documented component extension surface today.

Upgrade criteria for this specific release: grep your codebase for $data.state usage inside Modern-board Alpine components before bumping; Classic boards carry no stated risk. Add a visual/perf regression check on a representative large board, since the payload change is the most likely place to surface an unforeseen rendering dependency.

How to Pitch It (Stakeholders)

To executives: We can adopt the newest release of our board component to deliver three requested user-facing capabilities — grouping lanes, sticky lane labels, and collapsible lanes — at essentially zero engineering cost. The same release cuts the HTML we ship for a 125-card board by roughly 60% (2.6 MB → 1.0 MB), which improves load time on slower devices and networks without a redesign. Risk is contained: existing "Classic" boards are explicitly unchanged, and the only compatibility note affects an internal variable that was never a supported integration point. Recommend a scoped upgrade plus a quick audit of our Alpine code.

To engineering: v4.3.0 adds Modern-board features (group-by menu button, sticky lane labels, collapsible lanes), fixes click-vs-drag discrimination on card clicks, and removes per-card record embedding from the Modern board's HTML. Action items before merge: (1) grep for $data.state in any Alpine code touching Modern boards — it's removed, not deprecated; (2) perf-test a large board, since the payload change alters what's in the DOM; (3) confirm no snapshots/tests assert on board HTML size or structure. Classic boards need no regression pass.

To design/support: Users get grouping and collapsible lanes, plus a card that opens reliably on a slight click rather than fighting the drag handler. Support should expect fewer "card won't open" reports on Modern boards; Classic boards behave exactly as before, so guidance and screenshots need to distinguish board type.