@blaze folding breaks Flux <flux:select> — uncaught _activatable TypeError destroys all selects on the page

[dfkaraten]

What happens

After installing livewire/blaze (with no other changes), every <flux:select> / dropdown on a page becomes unstyled and unselectable. The console shows an uncaught error thrown from flux.js:

Uncaught TypeError: Cannot read properties of undefined (reading 'activate')
    at refresh (flux.js:5790)
    at displayEmptyAndCreateOptions (flux.js:5845)
    at HTMLElement.mount (flux.js:5648)

The throw aborts the rest of flux.js initialization, so all Flux selects on the page lose their JS behavior/styling — not just the offending one.

Trigger

A <flux:select searchable> that contains a <flux:select.option.create> and is empty on first load (e.g. a backend-searched picker whose options only populate after the user types):

<flux:select searchable variant="listbox" wire:model="categoryId">
    {{-- options come from a backend search; empty on first paint --}}
    <flux:select.option.create wire:click="startCategoryCreate">Create new</flux:select.option.create>
</flux:select>

Internally, the parent <ui-options>.mount() runs displayEmptyAndCreateOptions() and reaches create._activatable.activate(true) before the child <ui-option-create> custom element has mounted (so _activatable is still undefined).

It is NOT the fold layer

I published flux/select/options.blade.php and flux/select/option/create.blade.php and removed their @blaze(fold: true) directive — verified via ComponentSource that Blaze now reports fold: NULL for both. The crash persisted. Folding emits identical HTML, so it can't change the runtime custom-element mount order; the breakage comes from Blaze's compile/memo layer changing how Livewire morphs / the element connect–disconnect lifecycle. Confirmed by toggling BLAZE_ENABLED=false — selects work again immediately.

Workaround

BLAZE_ENABLED=false (or removing livewire/blaze) fully resolves it. There's no per-component / per-layer opt-out that helps, since fold isn't the cause.

Related

• Adding searchable to a flux:select which has the 'create' as a modal throws a JS error flux#2309 — same create._activatable is undefined error; fixed for the non-Blaze runtime case, but Blaze re-creates the "empty on first load" condition at the static/compile layer.
• Blaze issues with Pillbox search component flux#2291 — prior Blaze×Flux incompatibility (pillbox search) where the maintainers resolved it by stripping @blaze from the component. Suggests this may need the same treatment for the select/create path, or a guard in flux.js.

Versions

• livewire/blaze v1.0.12
• livewire/flux + flux-pro v2.14.1 (also reproduces on v2.15.0 — flux.js still unguarded, select views still ship @blaze(fold: true))
• livewire/livewire v4.3.1
• Laravel 13, PHP 8.4, Tailwind 4

[dfkaraten]

Update: root cause isolated — it is the fold/unblaze layer, and the trigger is a nested component/slot boundary, not "empty on first load"

I built a controlled, version-matched repro and was able to isolate this precisely. Two claims in my original report turned out to be wrong, so I want to correct the record:

• ❌ "empty on first load is the trigger" — it isn't.
• ❌ "it is NOT the fold layer" — it is. My earlier test (removing @blaze from the published option views) didn't isolate correctly because it never varied the thing that actually matters: whether the option nodes are direct children of <flux:select> or emitted through a nested component/slot.

Controlled setup

livewire/blaze v1.0.12, livewire/flux + flux-pro v2.15.0, livewire/livewire pinned to v4.3.1 (matched against a fresh Laravel 13 + Livewire-starter + Flux Pro install that works fine with Blaze), clean composer install with cleared cache. Important: composer require livewire/blaze silently floats the tree (it bumped Livewire 4.3.1→4.3.2 + framework 13.16→13.17 for me) — pinning Livewire to 4.3.1 rules that out: the crash reproduces at 4.3.1, so this is not a Livewire patch regression.

Repro matrix (one page, six searchable variant="listbox" selects)

#	Select	option/create authored as	Result
Control	empty-on-load, no create	inline (direct children)	✅ works
A	empty-on-load + create	inline	✅ works
B	populated + create	inline	✅ works
C	populated + create	emitted from a nested <x-options-wrapper> component slot	❌ crash
D	create inside a <flux:table>	inline	✅ works
E	create	emitted from an @include partial	❌ crash
F	whole <flux:select> (incl. option + create as direct children) wrapped in one component	inline within that component	✅ works

Takeaways:

• A disproves "empty-on-load is the trigger" (it's an empty-on-load create select, inline — works).
• D disproves any <flux:table> involvement.
• C and E isolate the real trigger: the folded flux:select.option.create is rendered through a nested component's slot or an @include instead of being a direct lexical child of <flux:select>.
• F is the fix (see below): the boundary moves above the whole select, so the folded option/create stay direct children within one template.

Mechanism (the actual bug)

Blaze folds Flux's own select/option/index.blade.php and select/option/create.blade.php (they ship @blaze(fold: …)) and restores each folded fragment's render scope at runtime via a token-keyed map (Unblaze::$unblazeReplacements / $unblazeScopes, [STARTCOMPILEDUNBLAZE:<token>]).

When the folded fragment is rendered through a nested component's slot (or an @include), that token lookup misses:

Undefined array key "i4bsE1GdRA" in vendor/livewire/blaze/src/Unblaze.php on line 87

…which is exactly where the code notes the limitation:

// Because unblaze content is not available at render-time during folding,
// its content wasn't trimmed when passing through slots and components.
$innerContent = Blaze::compileForUnblaze(static::$unblazeReplacements[$token]); // ← token missing
$scope        = static::$unblazeScopes[$token];

With the scope lost, the <ui-option-create> is emitted without its scope and never runs its custom-element mount(), so create._activatable is never assigned. flux.js then hits the unguarded path:

displayEmptyAndCreateOptions → refresh → create._activatable.activate()  // _activatable === undefined → TypeError

The uncaught throw aborts the rest of flux.js init, which is why every select on the page dies, not just the offending one.

Fix / workaround for Blaze users (no need to disable Blaze)

Keep folded Flux sub-components as direct lexical children of their parent in the same template — don't emit them from a nested component or @include. Concretely, if you DRY a picker into a component, wrap the whole <flux:select> rather than just its options:

{{-- ❌ boundary BETWEEN select and its options → unblaze token lost → crash --}}
<flux:select searchable variant="listbox" :filter="false" wire:model="categoryId">
    <x-category-options :options="$options" :create="true" />
</flux:select>

{{-- ✅ boundary ABOVE the whole select → option/create stay direct children → works --}}
<x-category-select :options="$options" :create="true" wire:model="categoryId" />
{{-- where <x-category-select> contains the <flux:select> + its option/create inline --}}

Suggested upstream fixes

1. Blaze: make the unblaze scope-restoration resilient when a folded fragment passes through a slot/component boundary (the Unblaze.php:87 token miss), or skip folding fragments emitted into slots.
2. Flux (defensive): guard the call — create._activatable?.activate?.(true) — so a not-yet-mounted <ui-option-create> can't take down all selects on the page. (Relates to flux#2309.)

Happy to share the full repro page if useful.