Blade slots no longer accept "falsy" values

[browner12]

• Laravel Version: 8.56.0
• PHP Version: 8.0.5
• Database Driver & Version: MySQL 8.0

Description:

Blade component slots no longer accept "falsy" values (null, '', 0, false, []).

For example:

• @slot('enabled', null)
• @slot('enabled', '')
• @slot('enabled', 0)
• @slot('enabled', false)
• @slot('enabled', [])

This causes the templating/layout system to break, which results in a messed up HTML output.

Reverting to Laravel 8.55.0 fixes the problem. My guess is this is caused by the changes to Blade in PR #38372.

Steps To Reproduce:

In a view, use a component that has a falsy value in a slot.

@extends('layouts.master')

@section('content')

    <div>Some Header</div>

    @component('some-component')
        @slot('key', false)
    @endcomponent

@endsection

[driesvints]

Ping @danharrin

[Jubeki]

I have setup a Repo for the falsy values: https://github.com/Jubeki/laravel-bug-report-38542

The dump output is as follows:

@component('components.component-with-slots')
    @slot('falsySlot', null)
    {{-- Dump: "" --}}
@endcomponent

@component('components.component-with-slots')
    @slot('falsySlot', 0)
    {{-- Dump: "" --}}
@endcomponent

@component('components.component-with-slots')
    @slot('falsySlot', '')
    {{-- Dump: "" --}}
@endcomponent

@component('components.component-with-slots')
    @slot('falsySlot', [])
    {{-- Dump: "" --}}
@endcomponent

@component('components.component-with-slots')
    @slot('falsySlot', 'TEST')
    {{-- Dump: "TEST" --}}
@endcomponent

@component('components.component-with-slots')
    @slot('falsySlot', 5)
    {{-- Dump: 5 --}}
@endcomponent

It seems to be converting the values to empty strings.

[danharrin]

Checking now and will submit another PR. One issue we have is that many parts of Blade are not currently testable, and this is one of them.

[danharrin]

@browner12 @Jubeki can you please check if #38546 fixes this?

[Jubeki]

Yes can confirm that it now is working as intended.

[browner12]

It does.

It seems like a good hotfix for now, but at first glance it seems like this may be prime for other issues in the future.

I'll admit I'm not super familiar with this code, though, so I'll have to dig in more.

Thanks for figuring this out!

[danharrin]

It seems like a good hotfix for now, but at first glance it seems like this may be prime for other issues in the future.

Eh it's not much of a "hotfix" as this is how the framework did this check before my PR - unless you're referring to the lack of tests.

[browner12]

hah, yah mostly referring to the fact that relying on the number of arguments passed is probably gonna cause us issues in the future....

I've got no other solution right now, so I'm happy with this solution!