[7.x] Compile Echos Within Blade Component Attributes

[taylorotwell]

Currently, you can not echo a PHP variable within an unbound Blade component attribute. Attempting to do so will just pass the entire literal string into the attribute uncompiled.

This is somewhat unexpected and can lead to some pretty bad DX. For example, when using Livewire, you would currently need to use bound attributes and the following dog and pony show to get things to work correctly:

<x-button :wire:click="'selectPlan(\''.$plan['id'].'\')" />

Which, I think everyone can agree is not intuitive at all. This PR will allow Blade echo statements within attribute strings to be compiled using the Blade compiler, so that you can do the more expected:

<x-button wire:click="selectPlan('{{ $plan['id'] }}')">

There are technically a couple breaking changes here. First, if you were literally trying to pass an attribute like foo="{{ something }}" and you did not want that evaluated by Blade, you would now need to do foo="@{{ something}}" using the normal Blade echo escape syntax.

Secondly, you may not pass literal PHP code as a string into an attribute. I think this would be even more rare, but this will cause issues: foo="<?php something; ?>".

In spite of these breaking changes I have sent this to the 7.x branch for consideration because I feel like it's such a point of confusion and bad DX that it could borderline be considered a bug.

[devcircus]

Agree it should go to 7. No doubt there will be a handful of apps that break, but in those cases blade is being pushed beyond its documented behavior.

[jameslkingsley]

Is there a way to infer parameter type to avoid having to explicitly pass string variables inside quotes?

Instead of doing:

<x-button wire:click="selectPlan('{{ $string }}')">

Can we do this?

<x-button wire:click="selectPlan({{ $string }})">

And have the compiler pass in $string encapsulated in quotes.

[taylorotwell]

I don't think so. I personally would expect to have to use single quotes in that case. Blade never wraps values in quotes auto-magically.

[joshhanley]

Would this also allow us to pass the attributes bag from a wrapper component through to another component?

I expected something like this to work:

<x-button {{$attributes}}>

But it doesn't instead you currently need to use:

<x-button :attributes="$attributes">

For example, it would be used when I have x-primary-button and x-secondary-button components that add styles to and wrap around x-button component.

I think that could improve the DX and make it consistent with how you use {{$attributes}} inside a component currently.

[taylorotwell]

@joshhanley totally unrelated issue. Feel free to PR a fix for that.

[AdamKyle]

The problem here that I have is the fact that it would be a breaking change to the way existing blade components and such work as of right now, thus it should wait till 8.0, while this might sound like a bug, to me it sounds like an ergonomic issue and while that can be unpleasant, I can’t see it being an issue that breaks things till at least 8.0. Especially if you are wanting to do proper semver.

These are just my thoughts and opinions.

[taylorotwell]

I'm not waiting months to fix this. Sorry.

[AdamKyle]

I'm not waiting months to fix this. Sorry.

While I agree with this, can you fix it such that maybe you add a deprecation notice, saying this way is being removed, please use this instead - that way you don't shatter peoples work and it still works and they know to fix it before 8.0.

Would that not make better sense from a semver perspective - every library and framework I know of does this instead of just shattering something.

[taylorotwell]

What is being removed? Nothing was removed or "shattered"? The old, ugly way you had to do this still works.

[AdamKyle]

You mentioned this was a breaking change. If it's a breaking change in a a.b.c (b) release then it should be postponed to 8.0 or done in some deprecated way. You stated clearly this was a breaking change and that you didn’t want to wait months. Hence the conversation we are having. If this is not a breaking change as you mentioned above then ignore me.

[calebporzio]

Here are my two cents:

Lots of newcomers get tripped up on this (some likely walk away from the project). I know this for a fact. I've watched people hit this issue live. I've hit it myself. I believe I've watched @freekmurze hit this issue as well.

It's something I know now and watch out for, but there are lots of people who may never get past it or switch to the old @livewire syntax instead (if they even realize that's a solution.)

(Update, just saw this:)