Ux Blocks Interactive Laravel Package

Product Decisions This Supports

• Build vs. buy for structured content editing. This package answers a recurring question — "do we build a block editor or adopt one?" It provides the editor shell (Blade components, x-ux-blocks-interactive.*, server-driven block state) while leaving your block taxonomy, persistence, and admin chrome to you. That split is favorable for a PM: you buy the interaction layer, you own the product model.
• Feature bets on structured content over WYSIWYG. If the roadmap includes landing pages, CMS-driven marketing pages, email/notification templates, or docs authoring, blocks give you re-renderable, validatable, migratable content instead of opaque HTML. This package makes that decision cheap to prototype and cheap to abandon.
• Scoping the "admin authoring" epic. The package collapses roughly the first third of an authoring epic (drag/reorder/edit UI, stimulus wiring, state hydration). It does not cover permissions, publishing workflows, previews, revisions, scheduling, media library, or block-level analytics — those stay on your roadmap and should be sized separately before committing a launch date.
• Data model decisions that are expensive to reverse. Adoption forces a JSON blocks column plus a block-type registry and a typed cast. That's a durable schema commitment; the decision to adopt is the decision to define a block schema. Worth an ADR.
• Roadmap risk budgeting. At v0.1.x with a single bugfix release and no published BC policy, this is an experiment/beta bet, not a platform bet. Treat it as a spike or an internal-tools dependency, not something a revenue-critical surface ships on without a fallback plan.
• Concrete first use cases worth validating: admin-managed marketing/landing pages on an existing Page model; a help-center or docs editor where block types map to content primitives; an internal tool where a small content team needs bounded, non-developer editing. Good "hello world": one block type (text) round-tripping through the JSON column before anything else.

When to Consider This Package

Consider it when:

• You're on Laravel and already use Blade + Vite, so the Stimulus/asset integration is a known quantity rather than new infrastructure.
• You have (or can add) an Eloquent model with a JSON content column and an admin surface — Filament, Nova, or a custom Blade admin — that can own the save flow.
• The content needs structure (ordered, typed, re-renderable blocks) rather than free-form rich text: templates, multi-channel publishing, or content that other systems consume.
• You can absorb an unstable API: you're willing to pin ^0.1, read CHANGELOG.md on every patch, and re-run a save-path feature test after each upgrade.
• The scope is bounded — an internal tool, an experimental surface, or a prototype where time-to-first-block matters more than long-term guarantees.

Look elsewhere when:

• You need a mature, supported, BC-guaranteed editor. A single star, one bugfix release, and no published BC policy are disqualifying for a revenue-critical authoring surface.
• Your need is really rich-text WYSIWYG (blog posts, prose-first editing) — a block editor is more ceremony than value there.
• You're not on Blade/Vite, or you already run a heavy Stimulus setup where controller identifier collisions become a maintenance tax.
• You require the surrounding authoring product (workflow, previews, revisions, roles) out of the box — you'd be buying a component and then building the product around it anyway.
• Your team won't own the block registry and per-block validation. Without a FormRequest validating each block type and a cast that hydrates null to an empty collection, malformed editor payloads become production 500s.
• Front-end asset ownership is unclear. The "loads in dev, dead in prod" Vite registration issue is an organizational risk as much as a technical one; if nobody owns resources/js/app.js, don't adopt.

Adoption criteria checklist: a JSON (not text) blocks column; a typed cast; per-block validation; one block type proven end-to-end; a documented upgrade ritual (pin, read changelog, diff vendor, run round-trip tests); published assets never hand-edited; and an explicit exit path if the package stalls.

How to Pitch It (Stakeholders)

For executives (30 seconds): We can get a structured, block-based content editor into our Laravel admin in days rather than weeks by adopting an early-stage open-source package. It covers the editing interaction; we still own content types, validation, permissions, and publishing. The hedge is that it's pre-1.0 — so I recommend we use it for an experimental or internal surface first, cap the investment, and keep our content in a portable JSON column so we can swap the editor without migrating data. Ask: approve a timeboxed spike, not a platform commitment.

For engineering (the honest version):

• What it gives us: server-defined blocks rendered as Blade components, Stimulus-backed interactivity, a config/registry extension point, and a component namespace (x-ux-blocks-interactive.*). We write block types and persistence; it writes the editor.
• What it costs us: a JSON blocks column and a block schema we'll live with; a custom AsBlocks cast; per-block FormRequest validation; Stimulus controllers registered in our Vite entry rather than relying on published assets; a namespacing decision to avoid controller collisions.
• What we accept: v0.1.x with no BC policy. We pin ^0.1, read CHANGELOG.md (not release notes — v0.1.3's body is just a link) before every patch, treat re-publishing assets as a one-way door, and feature-test the round trip — payload in → JSON column → re-hydrated blocks — because that's where patch upgrades break silently.
• What we refuse: extending vendor internals. We customize only through config, the Blade component namespace, and the model cast.
• Success looks like: one block type editing and saving reliably in a real admin screen, and a documented exit path if the package goes quiet. Then, and only then, do we talk about the second block type.