Wrapped listbox in custom component inherits option label

[ju5t]

Flux version

v2.10.2

Livewire version

v3.7.3

Tailwind version

v4

Browser and Operating System

Chrome on MacOS

What is the problem?

We have a custom component that wraps a flux:select. It uses the listbox variant.

This component has a label property that somehow gets inherited by the flux:select.option component. As a result, even though we set the $slot, the label gets preference over it.

<flux:select.option value="{{ $option['id'] }}" wire:key="{{ $option['id'] }}">
    <div class="flex items-center gap-2">
        {{ $option['name'] }}
    </div>
</flux:select.option>

I did some digging and found that even though we don't specify any variant on the select option, it doesn't use the default variant, but switches to the custom one.

The custom variant has:

{{ $label ?? $slot }}

Which results in the label of the parent component being used for each option instead of what we pass in its slot.

See also:
#1847

Code snippets to replicate the problem

php artisan make:view custom-component

And paste this in the blade file:

@props([
    'for',
    'label',
    'options' => [],
])

@php
    $listbox = collect($options)
        ->values()
        ->toArray();
@endphp

<flux:select {{ $attributes->whereDoesntStartWith('class') }} size="sm" variant="listbox">
    @foreach ($listbox as $option)
        <flux:select.option value="{{ $option['id'] }}" wire:key="{{ $option['id'] }}">
            <div class="flex items-center gap-2">
                {{ $option['name'] }}
            </div>
        </flux:select.option>
    @endforeach
</flux:select>

Example usage:

@php
$options = [
    ['id' => 'foo', 'name' => 'bar',],
];
@endphp

<x-custom-component :options="$options" />

Screenshots/ screen recordings of the problem

n/a

How do you expect it to work?

I would expect the slot to work and that it would not inherit the label from the parent component.

Please confirm (incomplete submissions will not be addressed)

• I have provided easy and step-by-step instructions to reproduce the bug.
• I have provided code samples as text and NOT images.
• I understand my bug report will be closed if I haven't met the criteria above.

[ganyicz]

Hi @ju5t,

thanks for reporting!

I'll just leave a note for myself here:

This is likely caused by <flux:delegate-component> which uses $__env->getCurrentComponentData() to provide data to the delegate target. The issue is that currentComponentData in BladeCompiler contains merged data of all parent components.

I'll post an update here when I find a good fix for this.

[ganyicz]

Hi @ju5t,

It turns out this is a pretty deep issue rooted in Flux's attribute forwarding to variants.

I'm not sure if we will be able to fix this any time soon because any solution might be potentially a breaking change.

However you can easily fix this in your app just by defining the label prop in addition to value:

@foreach ($listbox as $option)
  <flux:select.option value="{{ $option['id'] }}" label="{{ $option['name'] }}">
          {{ $option['name'] }}
  </flux:select.option>
@endforeach

This will force the actual option label so that it doesn't get inherited.

---

For @calebporzio

When a user-land component like <x-select label="Industry"> uses <flux:select> and/or <flux:select.option> inside, the label prop will be automatically inherited:

{{-- resources/views/welcome.blade.php --}}

<x-select label="Industry" />

{{-- resources/views/components/select.blade.php --}}

@prop(['label'])

<flux:select size="sm" variant="listbox">
    <flux:select.option>Photography</flux:select.option>
    <flux:select.option>Design services</flux:select.option>
</flux:select>

As mentioned in the above comment, this is caused by <flux:delegate-component> which forwards all attributes to the component it delegates to.

However it also inherits data of all parents in the component stack.

Furthermore, in most of our components we prefer label from attributes over the slot:

{{ $label ?? $slot }}

• An easy fix would be to reverse the order here, however there are 15 occurances of this pattern in flux.
• A proper fix would be to update delegate-component to only forward data of the current component.

Both could cause unforseen breaking changes

Additionally, we rely on slots being forwarded even from distant parents in some components, this just adds on the complexity.

Could be potentially solved by the new Blaze compiler if that would be enabled by default in Flux?

[ju5t]

@ganyicz no worries, appreciate the time you spent researching this. We've worked around it, so we're not in any rush here.

[calebporzio]

i'm attracted to this solution: An easy fix would be to reverse the order here, however there are 15 occurances of this pattern in flux.

Can we look into the impact of switching this across flux?

if negligible, I say we do it. If not, I say we still do it but just for this component.