Using a component which exposes a {{ $slot }} results in a compilation failure when the slot value is directly preceding (without any spaces) the closing tag of said component.
Say you have a component example.blade.php
<div>{{ $slot }}</div>
Using it the following way will work just fine. In fact as long as you keep a space between the value
and the closing tag, all is fine and the view gets compiled.
<x-example>
Some random content
</x-example>
But if for some reason you decide you want everything on the same line without additional spaces, the compilation will fail.
<x-example>Some random content</x-example>
The previous template gets compiled down to this PHP code:
<?php if (isset($component)) { $__componentOriginalc254754b9d5db91d5165876f9d051922ca0066f4 = $component; } ?>
<?php $component = app()->make(Illuminate\View\AnonymousComponent::class, ['view' => 'components.example','data' => []]); ?>
<?php if ($component->shouldRender()): ?>
<?php $__env->startComponent($component->resolveView(), $component->data()); ?>
<?php $component->withAttributes([]); ?>Some random content@endcomponentClass
As you can see, the @endcomponent Blade statement did not get compiled. This happens because the method responsible for parsing these statements uses the \B anchor in its regex pattern. This forbids the blade statements to be preceded by characters that are not word boundaries.
I'm pretty sure removing this \B would solve the problem but at the same time I think it's here for a good reason. As pointed in https://github.com/laravel/framework/pull/5662, it might be there to prevent parsing errors when someone hardcodes an email address in his template because if the hostname contained the name of a Blade statement, it would break things.
For example, this would trick the compiler into closing a component.
<x-example>[email protected]</x-example>
My current workaround is to use the component on multiple lines or inserting a trailing space to the slot value.
Should this not get fixed, I think it would be a good idea to be crystal clear about it in the documentation.
Any ideas ?
Cheers
I was about to post the same issue. Trailing space works for now but may cause bugs when your IDE decides to strip them.
I can reproduce this. It's indeed fixed when I remove the "B" character from that regex.
The thing with this solution is that It feels more like a hack than anything else. The idea of potentially breaking the parsing of these special email addresses (rare as they may be) feels wrong. Should we maybe look for an alternative way ?
@nhedger maybe try sending this in with a test with exactly an email address in it.
Taylor pushed a fix for this. Thanks!