[8.x] Blade component slot attributes

[danharrin]

This PR further enhances the power of Blade components by allowing slots to have their own attributes. 🚀

Take this card component example:

@props([
    'heading',
    'footer',
])

<div {{ $attributes->class(['border']) }}>
    <h1 {{ $heading->attributes->class(['text-lg']) }}>
        {{ $heading }}
    </h1>

    {{ $slot }}

    <footer {{ $footer->attributes->class(['text-gray-700']) }}>
        {{ $footer }}
    </footer>
</div>

<x-card class="shadow-sm">
    <x-slot name="heading" class="font-bold">
        Heading
    </x-slot>

    Content

    <x-slot name="footer" class="text-sm">
        Footer
    </x-slot>
</x-card>

In this example, I am able to fully customise multiple areas of the Blade component, not just its outer container. By passing the class attribute to both slots, I can make the heading bold and the footer smaller without having to create another view just for this use case.

Let me know if you have any questions about this implementation, or you can see any areas that could be improved!

[dennisprudlo]

That would be awesome if merged. Currently I use some custom props like inner-class or <slotname>-class. This would cleanup the components a lot!

[taylorotwell]

While I appreciate this feature, I want to really make sure it's needed. In both of your examples could you not have just done this type of thing:

    <x-slot name="heading">
        <span class="font-bold">Heading</span>
    </x-slot>

Does Vue support this?

[stancl]

@taylorotwell Remember when we talked about scoped slots for Blade? In the implementation I used (https://twitter.com/samuelstancl/status/1390655396927447043), I had no way to access other attributes on the <x-slot> call. So I had to use <x-slot name="scoped:foo">

Dan's feature would let me use:

<x-slot name="foo" scoped>

</x-slot>

I'm actually happy to contribute the scoped slots feature if Dan's PR is merged. The code is super simple and the only ugly bits currently are the ones that check the scoped: prefix in the name — which wouldn't be a thing after this change.

[danharrin]

Thanks for the consideration! This is definitely needed.

The example I gave was purely of the implementation really, I agree that it's not a good example to demonstrate its power.

Where this really comes in useful is outside of simple class territory. For example - if the wrapper around the slot is not a simple <div> and has more specialised attributes, you may want to pass attributes to that element - which cannot be done by creating a child element.

<textarea {{ $textarea->attributes }}>
    {{ $textarea }}
</textarea>

And - Vue does not support this yet, but I saw someone mention earlier that they'd love it if it was 😅

[binaryweavers]

As per need it's good to have when you extract the components in a package with most of the functionality implemented in component and you might want to avoid extra markup.
Another example can be a dropdown component having activator which can have own styling and html tag etc 🤔
We are currently using this in our projects where we have extracted UI components and just pull them in

@php

$activatorTag = $activtor->attributes->get('tag', 'div');

@endphp
<{{ $actrivatorTag }}
      {{ $activator->attributes->except(['tag'])->class(['transition-all']) }}
      x-ref="activator"
      x-on:click="openOnClick && !isActive ? show() : hide()"
      x-on:focus.debounce.150ms="openOnFocus && show()">

        {{ $activator }}

</{{ $actrivatorTag }}>

<x-dropdown>

     <x-slot name="activator" class="..."  tag="button" disabled>

            Settings

     <x-slot>

     ...
    
</x-dropdown>

[binaryweavers]

@danharrin I see that implementation is almost same as we are using. We faced an edge case when using this approach in DynamicComponent .

framework/src/Illuminate/View/DynamicComponent.php

Line 120 in 3591526

protected function compileSlots(array $slots)

    protected function compileSlots(array $slots)
    {
        return collect($slots)->map(function ($slot, $name) {
            return $name === '__default' ? null : '<x-slot name="'.$name.'">{{ $'.$name.' }}</x-slot>';
        })->filter()->implode(PHP_EOL);
    }

I solved this overriding dynamic component like so
https://github.com/binaryweavers/laravel-blade-slots-plus/blob/25c33259cf5f60b2b18c70e222e50397fdeac0c6/src/DynamicComponent.php#L35

    protected function compileSlots(array $slots)
    {
        return collect($slots)->map(function ($slot, $name) {
            $slot->attributes = ($slot->attributes instanceof ComponentAttributeBag) ? $slot->attributes : new ComponentAttributeBag();
            $slot->attributes->setAttributes($slot->attributes->getAttributes());
            return $name === '__default' ? null : '<x-slot name="' . $name . '" ' . $slot->attributes->__toString() . '>{{ $' . $name . ' }}</x-slot>';
        })->filter()->implode(PHP_EOL);
    }

[taylorotwell]

@danharrin any thoughts on the dynamic component note above?

[danharrin]

@taylorotwell I'll add a test for dynamic components to check it's an actual issue, because looking at @binaryweavers code, I can't see why that would do anything but replace the already existing slot attribute bag 😅 it should be created when the slot is constructed, so should always be present.

[binaryweavers]

@taylorotwell I'll add a test for dynamic components to check it's an actual issue, because looking at @binaryweavers code, I can't see why that would do anything but replace the already existing slot attribute bag 😅 it should be created when the slot is constructed, so should always be present.

Haha TBH, I am not sure why I did that, I was lacking time and was facing an issue as well (you see I don't have tests as well 🤦‍♂️).
I'll try to reproduce why I did that and update 👍🏼
As I am overriding native stuff a lot but something was causing issue that time which got fixed this way. I was on code & fix strategy at that time 😂

[danharrin]

Looks like this works fine if you cast the attributes to a string and pass them through normally 👍 No need to reset the attribute bag.

[binaryweavers]

Okay, the actual problem with dynamic components is rooted here, so I don't know how tf @binaryweavers' code actually worked ahah 😅 I'll think about the best way to fix this, but I don't think it's gonna be too easy :(

Hahah don't worry I got you covered and backtraced that confusing part of mine code 😂 I see that you missed that too. Here is the breakdown first.
Just like you also forgot to update this line

framework/src/Illuminate/View/Concerns/ManagesComponents.php

Line 104 in 8cbdf8f

$defaultSlot = new HtmlString(trim(ob_get_clean()));

and $slot->attributes were not working as it gets collected in componentData method.
then I blindly patched those confusing lines in DynamicComponent 🤦‍♂️
Then later on I updated here . So Those two line are just doing nothing there now.

[danharrin]

@binaryweavers @taylorotwell I think I've fixed it, but have a check yourselves if you wish!

[binaryweavers]

Looks like this works fine if you cast the attributes to a string and pass them through normally 👍 No need to reset the attribute bag.

Yes they are unnecessary after making default $slot an instance of ComponentSlot in componentData method

[taylorotwell]

Note that XSS is possible due to bound attribute escaping being disabled:

[driesvints]

@danharrin tests are failing

[danharrin]

@taylorotwell I tested your example and, as far as I can see, escaping bound attributes has no effect on slot attribute output or component attribute output. Am I missing something?

[taylorotwell]

Clear your compiled views. It does escape for me when I switch to escapeBound = true on slot data.

[danharrin]

Clear your compiled views. It does escape for me when I switch to escapeBound = true on slot data.

Yeah I had cleared them and the issue was there to start with. It's all good as long as you're happy with it working as you expect :)

[taylorotwell]

Hmm - there is still the XSS vulnerability in the PR? Any user provided data that is bound such as alt text, etc. will be vulnerable to XSS.

[taylorotwell]

Ah, nevermind, I see you started escaping them now.

[thewebartisan7]

Nice feature that I missed time ago. Thanks.

Seem not possible to pass to a component the slot attributes, like:

<div {{ $attributes) }}>

   <x-mycomponent {{ $myslot->attributes->class('my-class') }}>{{ $myslot }}</x-mycomponent>

    {{ $slot }}

</div>

[thewebartisan7]

This doesn't work:

<x-my-component {{ $myslot->attributes }}>{{ $myslot }}</x-my-component>

While this works:

<x-my-component :attributes="$myslot->attributes">{{ $myslot }}</x-my-component>

But with main $attributes this works:

<x-my-component {{ $attributes }}>{{ $slot }}</x-my-component>

@danharrin is this expected behaviour?

The error message is: "syntax error, unexpected token "else", expecting end of file "

[dennisprudlo]

@thewebartisan7 This components rendering with arbitrary blade-injected content is not possible at the moment. You can't use {{ $something }} in the component tag as well as you can't use blade directives such as this:

<x-my-component @if ($condition) class="text-red-500" @endif>
    {{ $slot }}}}
</x-my-component>

Your second example works because you bind $myslot->attributes directly to a prop and the third example works because it is explicitly allowed (because passing $attributes down that way is a very common and ultimately needed use-case):

https://github.com/laravel/framework/pull/38372/files#diff-bddd3c3babe9b0302fb60bf7836b9177618530224733a4f20ef5286313eec6dcR408-R410

[thewebartisan7]

That make sense. Thanks.

[yaddly]

This PR further enhances the power of Blade components by allowing slots to have their own attributes. 🚀

Take this card component example:

@props([
    'heading',
    'footer',
])

<div {{ $attributes->class(['border']) }}>
    <h1 {{ $heading->attributes->class(['text-lg']) }}>
        {{ $heading }}
    </h1>

    {{ $slot }}

    <footer {{ $footer->attributes->class(['text-gray-700']) }}>
        {{ $footer }}
    </footer>
</div>

<x-card class="shadow-sm">
    <x-slot name="heading" class="font-bold">
        Heading
    </x-slot>

    Content

    <x-slot name="footer" class="text-sm">
        Footer
    </x-slot>
</x-card>

In this example, I am able to fully customise multiple areas of the Blade component, not just its outer container. By passing the class attribute to both slots, I can make the heading bold and the footer smaller without having to create another view just for this use case.

Let me know if you have any questions about this implementation, or you can see any areas that could be improved!

Good day and thank you for this invaluable and educative post. May I ask if it is possible to check if a named slot has data/content before rendering its content? In other words, how do I make named slots optional? An if statement using the named slot throws an error, your guidance would be highly appreciated.

@if(!$footer->isEmpty())//This line throws Undefined variable $footer
{
    {{$footer}}
}
@endif

However, when you check for emptiness on the main slot, it works.

@if(!$slot->isEmpty())
{
     {{$slot}}
}
@endif

Without the ability to make named slots optional, one is now compelled to litter code with empty named slots just to avoid errors

<x-slot name="footer"></x-slot>

[danharrin]

If your slot is nullable, you should delare it in @props(['footer' => null])

Then you can just use @if ($footer?->isNotEmpty())

[yaddly]

If your slot is nullable, you should delare it in @props(['footer' => null])

Then you can just use @if ($footer?->isNotEmpty())

Thank you very much for guiding me into resolving the error I had.