@aware property values lost when rendering a named slot with `{{ $slotName }}`

[hctorres02]

Laravel Version

12.32.5

PHP Version

8.2.29

Database Driver & Version

No response

Description

When analyzing the behavior of the Blade components, the following sequence can be observed:

• In x-slot:search, the is-grouped property is defined, and its value is true.
• In x-form.field, the value of isGrouped is also true, as defined in the component’s @props.
• However, in x-form.input, the value of isGrouped becomes false (the default).

This indicates that the property value is lost during the rendering of the slot inside the x-table component.

The reason lies in how Blade handles named slots. When the search slot is rendered using {{ $search }} within x-table, Blade re-renders the slot content as a new, isolated instance, without preserving the parent component’s context or properties (x-form.field).

As a result:

• The x-slot:search keeps is-grouped=true.
• The x-form.field also sees isGrouped=true while it renders.
• But when {{ $search }} is used, the slot content is rendered outside the x-field scope, so inner components like x-form.input and x-form.button do not receive the @aware values.

In contrast, inside x-form.field, when {{ $slot }} is used, Blade maintains the component scope, and the aware variables remain accessible — which explains why x-input correctly recognizes the isGrouped value in that case.

In summary:

The value of the isGrouped (or hasAddons) property is lost when the slot content is rendered outside the scope of the component that defines it, such as when using {{ $search }}. This happens because Blade recompiles the slot content in isolation, without preserving variables and properties propagated through @aware.

Steps To Reproduce

{{-- component: field --}}
@props([
    'hasAddons' => false,
    'isGrouped' => false,
])

<fieldset @class([
    'field',
    'has-addons' => $hasAddons,
    'is-grouped' => $isGrouped,
])>
    {{ $slot }}
</fieldset>

{{-- component: input --}}
@aware([
    'hasAddons' => false,
    'isGrouped' => false,
])

@props([
   // ...
])

@if ($hasAddons || $isGrouped)
    <input {{ $attributes }} />
@else
    <fieldset class="field">
        <input {{ $attributes }} />
    </fieldset>
@endif

{{-- component: table --}}
<div>
    @isset($search)
        <x-form>
            <x-form.field :is-grouped="$search->attributes->has('is-grouped')">
                {{ $search }}
            </x-form.field>
        </x-form>
    @endisset

    <table>
        {{ $slot }}
    </table>
</div>

{{-- view: home --}}
@section('main')
    <x-table>
        <x-slot:search is-grouped>
            <x-form.input placeholder="Título" name="title" is-size="normal" is-expanded />
            <x-form.button icon="search" is-size="normal" />
        </x-slot>
        @forelse ($posts as $post)
            <tr> ... </tr>
        @empty
            <tr> is empty </tr>
        @endforelse
    </x-table>
@endsection

Sources:

• button
• input
• field
• table
• home

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[hctorres02]

I was following the flow and noticed that in the slot context, the attribute references are from the closest component, even though they're written in the way PHP interprets the code (top-down).

I think I could merge the slot attributes with the component properties, but this could have some undesirable side effects. However, by understanding Blade's behavior of discarding variables in each context (lines 68 and 72), this could be mitigated [somehow].

Or perhaps there could be a way to define @aware for slots, making everything much more explicit and less confusing.

[faisuc]

I can reproduce this. The behavior comes from how Blade captures and renders named slots:

• Slot content is captured eagerly (ob_start / ob_get_clean) before the parent component is on the stack.
• During that capture, @aware cannot resolve values from the parent, so it falls back to defaults.
• The captured content is then stored as plain HTML and later echoed via {{ $search }}, which means it is not re-evaluated in the parent component’s scope.

Given that slots are rendered eagerly, this is a limitation of the current architecture rather than a simple bug.

Workarounds that avoid the scope loss:

1. Pass context explicitly on the slot

<x-slot:search :is-grouped="true">
    <x-form.input placeholder="Search" />
</x-slot>

2. Restructure so the context provider wraps the slot usage

<x-form.field :is-grouped="true">
    <x-table>
        <x-slot:search>
            <x-form.input placeholder="Search" />
        </x-slot>
    </x-table>
</x-form.field>

3. Prefer explicit props on inner components instead of @aware

<x-form.input :is-grouped="$isGrouped" />

Addressing this in core would likely require deferred (lazy) slot evaluation or a separate mechanism for slot-scoped awareness, which would be a larger change with BC and performance considerations. If there is interest in exploring that direction, I am happy to help investigate an approach.

[hctorres02]

I already assumed the content was passed as raw HTML to {{ $search }}.

The suggestion to wrap the x-table component with x-form wouldn't be reasonable in cases where the table is required as the first element.

As I suggested in my previous observation, making the component's use of @props explicit is ideal. Something like {{ $search->withProps([ ... ]) }} (or withAware).