Embed a Drag-and-Drop Builder in Laravel Livewire (the wire:ignore trick)

wire:ignore is the whole trick

Livewire keeps a DOM in sync with server state by morphing: after every action it renders the component on the server and diffs that HTML against what is in the browser, patching the differences. BuilderJS, the moment you construct it, mutates that same DOM heavily — it injects the canvas, the widgets palette, the settings panel, drag handles, and overlays. So on the next Livewire round-trip the morph compares the editor's live markup against the component's original (now stale) render and starts removing and rewriting nodes the editor created. The canvas flickers, overlays vanish, drag handles detach. The fix is a single attribute: put wire:ignore on the wrapping element (or wire:ignore.self if you only want to skip the element itself). Livewire then treats that subtree as opaque and never morphs it, so BuilderJS owns those nodes uncontested for the component's lifetime. This is the standard, documented way to host any DOM-owning JavaScript widget inside Livewire — it is not a hack, it is the intended escape hatch. Wrap the three container divs the editor mounts into (canvas, widgets, settings) in one wire:ignore parent and the DOM fight disappears entirely.

Mount window.Builder in Alpine x-init (or a @script block)

BuilderJS ships as a compiled browser bundle, not a Composer or npm package, and loading builder.js attaches a global named window.Builder. There is no module export, so never write import { Builder } from anything. You need two things: the global present on the page, and a client-side hook that fires once after the DOM exists. In Livewire the two clean options are Alpine and @script. With Alpine — which ships with Livewire 3 — give the wire:ignore wrapper an x-init that runs the mount: new window.Builder({ mainContainer: '#bjs-canvas', widgetsContainer: '#bjs-widgets', settingsContainer: '#bjs-settings' }). Those options are CSS selector strings passed to querySelector — not refs, not DOM nodes. Only mainContainer is required; the other two are optional sidebars. Alternatively, Livewire's @script directive runs JavaScript exactly once when the component is initialized and is not re-executed on subsequent updates, which is precisely the lifecycle a single-instance editor wants. Either way, construct the builder once and keep the reference (on the Alpine component, or a module-scoped variable) so you can call getData() and load() later. There is no destroy() method — on a real teardown Livewire/Alpine discards the container DOM and the editor goes with it; never call builder.destroy(), it does not exist.

Bridge save: $wire.save(builder.getData()) or a plain fetch

Persistence is plain JSON and stays entirely on your side — BuilderJS does not send, host, or publish anything. To capture the design call const data = builder.getData(), which returns a lossless snapshot of the canvas, and builder.getHtml() for the rendered markup. You have two natural bridges back to the server. The Livewire-native path: call $wire.save(builder.getData()) from your mount scope — $wire is the magic object Livewire exposes for invoking PHP actions from JavaScript — and a public save($data) method on your component validates and persists it to your model (a designs table, a JSON column, wherever). The framework-neutral path: POST the JSON to one of your own routes with a plain fetch, sending Laravel's CSRF token in the headers. Both are equivalent; choose $wire when you want the save to flow through your component's lifecycle and validation, and fetch when you want the editor's save to stay independent of Livewire's request cycle. Note that BuilderJS also offers a built-in builder.save() that POSTs html and data url-encoded to the saveUrl you pass in the constructor — handy for a non-Livewire route — but there is no save:click event, so wiring a save button to $wire or fetch is host-driven by design. To reopen a design, echo the stored JSON into the view and call builder.load(themeJson, themeTemplatesJson, themeConfigData, mediaUrl) — four positional arguments, in that order. The data lives in your database; the editor imposes no storage backend.

One editor for both email and landing pages

The same Livewire-hosted editor produces two distinct outputs, so a single integration can power both your transactional-email template editor and your marketing landing-page editor. For web and landing pages it emits responsive, modern-CSS HTML. For email it runs an export pipeline that rewrites the document to survive the real world of inboxes: flexbox and grid layouts become nested presentation tables, Outlook MSO conditional comments and ghost tables are injected, @media (max-width:600px) rules collapse the layout to a mobile stack, images go fluid (max-width:100%; height:auto), SVG icons rasterize to PNG, and a CSS inliner finishes the job. The bundled 30+ templates and 200+ samples were Litmus-tested across 22 email clients, with RTL and 20+ locales available. BuilderJS builds the markup in each case; bringing an ESP to actually send the email, or a host to serve the page, is your application's responsibility — it is the editor, never the delivery platform.

Own the source with a one-time license

BuilderJS is sold once on CodeCanyon (item 27146783) as Regular $52 or Extended $99 — you get the source, self-host builder.js and builder.css from your own origin, and embed it in as many of your own Livewire screens as the license tier allows. There is no SaaS subscription, no monthly bill, no per-seat charge, no usage metering, and no phone-home telemetry; your only ongoing cost is the Laravel server you already run. Because the bundle has no external runtime dependency on a vendor service, your app stays fast and private and your customers' designs live in your database as portable JSON. You extend it without forking — register custom Elements, Widgets, and Controls, theme the editor chrome to match your product, and localize with built-in i18n. The honest boundary: author support and version updates through CodeCanyon are time-boxed (roughly 6–12 months), after which you keep and maintain the source you already own. Try the full getData()/load() round-trip on the live demo at builder.emotsy.com before you commit.

Frequently asked questions

• Why does my BuilderJS canvas break or flicker inside a Livewire component? expand_more

  Because Livewire morphs (re-renders and diffs) the component's DOM on every server round-trip, and BuilderJS mutates that same DOM to build its canvas, palette, and overlays. The morph then fights the editor, rewriting nodes the editor created. Wrap the editor's container in wire:ignore so Livewire treats that subtree as opaque and never touches it. That single attribute fixes it — it is the standard escape hatch for hosting any DOM-owning JS widget in Livewire.

• Where should I mount window.Builder — x-init or @script? expand_more

  Either works. Alpine's x-init on the wire:ignore wrapper runs your new window.Builder({...}) once after the DOM exists, and Alpine ships with Livewire 3. Livewire's @script directive also runs JavaScript exactly once on component init and is not re-run on updates, which suits a single-instance editor. Construct the builder once, keep the reference, and pass CSS selector strings (not refs) for mainContainer, widgetsContainer, and settingsContainer.

• Is there a Livewire component or Composer/npm package for BuilderJS? expand_more

  No. BuilderJS is a self-hosted browser bundle that attaches window.Builder when builder.js loads — there is no Composer package, no npm package, and no module export. You copy builder.js and builder.css into public/, load them in your view, and call new window.Builder(...). The same files are framework-agnostic and run identically in plain Blade, Livewire, React, Vue, or Angular.

• How do I save the design from Livewire — $wire or fetch? expand_more

  Both work. Call builder.getData() for a lossless JSON snapshot, then either invoke a Livewire action with $wire.save(builder.getData()) so the save flows through your component's validation and lifecycle, or POST the JSON to your own route with a plain fetch (include Laravel's CSRF token). BuilderJS also has a built-in builder.save() that POSTs html+data to the constructor's saveUrl, but there is no save:click event, so wiring the save button to $wire or fetch is host-driven by design. To reopen, echo the stored JSON into the view and call builder.load(themeJson, themeTemplatesJson, themeConfigData, mediaUrl).

• Does BuilderJS send the email or host the page it builds? expand_more

  No. BuilderJS is the embeddable editor only — it builds and exports the markup (responsive page HTML, or Outlook-safe email HTML through its export pipeline) and hands it back as JSON via getData(). Your Laravel app owns persistence, and you bring your own ESP to send the email or your own host to publish the page. That clean editor-not-platform split is by design so you keep full control of delivery and storage.