Using $attributes-Bag on Flux:Modal-Component

[ThomasEnssner]

Describe the bug
After installing Blaze the FluxModal component causes a parse error if you use {{ $attributes->class('space-y-6') }} on the component "call".

my own component "x-livewire-modal" wraps the flux:modal for setting default layout like headlines and buttons and so on...

Component causing the issue

<!-- resources/views/components/livewire-modal.blade.php -->
@props(['heading' => null, 'buttons' => null])

<flux:modal wire:model.self="showModal" :name="$this->getName()" {{ $attributes->class(['space-y-6']) }}>
  <div>
    @if($heading)
      <flux:heading size="lg">{{ $heading }}</flux:heading>
    @endif
  </div>

  {{ $slot }}


  <div class="...somestyles...">
    @if (filled(trim((string) $buttons)))
      {{ $buttons }}
    @else
      <flux:modal.close>
        <flux:button variant="ghost">Schließen</flux:button>
      </flux:modal.close>
    @endif
  </div>
</flux:modal>

Expected behavior
Should work as there is no blaze installed.

Actual behavior

Environment

• Laravel version: 12.
• PHP version: 8.4
• Flux (pro): 2.6.1,
• Blaze: 1.0-beta1
• Livewire: 3.6.4

Additional context
removing the {{ $attributes->class(['space-y-6']) }} addition would fix the parse-error.
But I use the class forwarding here to adjust the width of the modal.

[cyppe]

Dont know if its same issue - but when running livewire v4 beta 3 + installed blaze, it seems like most flux components does not handle dynamic values anymore.

For example:

 <flux:badge
    :color="$statusColor"
    size="sm"
    :variant="$statusVariant"
>
    {{ $statusText }}
</flux:badge>

Doesnt work.

It just renders the default colors etc.

But then if I go into the badge component in vendor package and remove @blaze directive it works again.

[swist666]

Same here.

<flux:modal {{ $attributes }}>
    {{ $slot }}
</flux:modal>

This doesn’t work with Blaze. Without ⁠{{ $attributes }}, it works just fine.

The issue seems to be caused by these lines:

/livewire/flux/stubs/resources/views/flux/modal/index.blade.php:

// Support <flux:modal ... @close="?"> syntax...
// Support <flux:modal ... @cancel="?"> syntax...


When I remove those comments, everything works correctly.

[jdlien]

I've discovered this issue and may have a bit more info and a suggested fix:

Root cause location: Tokenizer.php:85-162

The handleTextState() method scans for component prefixes (<flux:, <x-, etc.) without tracking parser context. It doesn't know when it's inside:

• PHP comments (// ...)
• PHP strings
• blocks

So when it encounters:
// Support <flux:modal ... @close="?"> syntax...

It sees <flux:modal and starts parsing it as a real component tag, corrupting the compiled output.

Fix: The tokenizer needs context awareness—either skip blocks entirely before tokenizing, or maintain a state stack that tracks when the parser is inside PHP comments/strings.