Statamic Flow Canvas Laravel Package

Product Decisions This Supports

• Build vs. buy for graph/flow UIs. Seven named components (Canvas, NodeCard, NodeLibrary, ControlBar, AdderNode, InsertableEdge, PropertiesSection) describe a fairly complete node-editor surface. This package is the argument for buying the canvas and building only your domain logic — node types, validation, persistence, permissions.
• Roadmap unblocking. Any feature that is a DAG, pipeline, dependency map, decision tree, or workflow builder becomes a weeks-not-quarters item. The 1.6.1 change specifically lowers the evaluation cost: a PM can approve a one-day spike knowing the styling will not depend on a host build-config change.
• De-risking the "vendor CSS" tax. Until now, correct rendering depended on the host's Tailwind content globs scanning vendor/. That is an invisible, per-host, per-upgrade configuration task that fails silently and is usually diagnosed as "the package is broken." Moving the seven affected components to scoped fc- classes removes a class of integration bug that generates support load disproportionate to its severity.
• White-labeling and multi-tenant theming. Colours now come from CSS variables rather than baked hex values or utility classes. That is a real product capability: per-tenant brand palettes can become a runtime theme swap instead of a CSS rebuild.
• Sequencing. Because the change is style-only and guarded by tests/js/plain-css.test.js, it does not compete with other roadmap items for engineering review time. It is a cheap upgrade that improves the onboarding story you tell in docs.

When to Consider This Package

Adopt when:

• You are on Laravel and want the editor embedded in Blade/Livewire/Inertia without adopting a separate JS app.
• Your host stylesheet is Tailwind, Bootstrap, CSS Modules, or hand-rolled — the plain-CSS change means the package no longer assumes your build scans vendor/.
• You expect to theme or white-label the editor; CSS variables are now the supported override surface.
• You are evaluating the package rather than committing: verify the seven components render correctly in your app shell, not just the package demo.

Look elsewhere or delay when:

• Strict CSP. A scoped <style> block per component can require style-src 'unsafe-inline'. If your app ships a hardened CSP, confirm this before adoption — the fix trades one integration hazard for a potentially harder-to-negotiate one.
• Deep design-system coupling. If the product requirement is that the editor be indistinguishable from your Tailwind token system, you now override via CSS variables and fc- selectors rather than by composing utilities. That is more robust but less ergonomic for fine-grained visual work.
• You already forked or targeted the old utility classes. Any host CSS that overrode those seven components by matching Tailwind utility names will silently stop applying. Pin, upgrade, and do a visual QA pass rather than reading "patch release" as "no visual delta."
• You need a large third-party ecosystem (plugins, connectors, React/Vue interop). A Laravel-scoped package will not match a dedicated graph library's ecosystem; choose deliberately.
• Your dark mode does not use a .dark ancestor class. The :global(.dark) selector is an explicit assumption about how your app toggles themes. Verify it matches your convention (class vs. prefers-color-scheme vs. data-theme).

How to Pitch It (Stakeholders)

To executives: This release removes a recurring source of "the editor looks broken" reports. Previously, correct rendering depended on each host app configuring its build to scan the package — a step that is easy to miss, hard to notice, and unrelated to anything the user did. Those seven components now carry their own scoped styles, so the editor renders correctly on install. Practically, this shortens time-to-first-value on any graph or workflow feature and lets us offer per-customer theming without per-customer builds. Scope is small and patch-level, but the integration risk it retires is not.

To engineering: Styling for the seven shared components moved from Tailwind utilities to fc- classes inside scoped <style> blocks, with values held identical — hex colours replaced by CSS variables, dark mode via :global(.dark). Utilities outside the affected list are untouched. A JS test (tests/js/plain-css.test.js) guards against regression. Two things to check before merging: (1) any local overrides that targeted the old utility class names need to be rewritten against fc- classes or the CSS variables, and (2) if we run a strict CSP, confirm the inline <style> blocks do not require an unsafe-inline exemption we are unwilling to grant. No PHP API or component-prop changes are implied by these notes.