And what about something like this ?
class Foo extends Component {
public $bash;
public function __construct( $bash, $xyz ) {
$this->bash = $bash;
}
}
Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I would love to have the ability to call a setter method when using a Blade Component, rather than forcing the parameters to be in the constructor of the class.
For example:
<x-foo-component bash="boo" xyz="abc" />
currently (as I understand it) needs:
use Illuminate\View\Component;
class Foo extends Component {
public function __construct( $bash, $xyz ) {
...
}
}
However, what would be awesome would be to be able to do:
use Illuminate\View\Component;
class Foo extends Component {
public function __construct( $bash ) {
...
}
public function setXyz($val) {
... setter code ...
}
}
where setXyz() gets called as the component is set up.
On the face of it, this does the same thing, but I have a suite of components with various shared features and I'd love to work better with Traits and inheritance. The insistence on constructor params is unwieldy and leads to a lot of code duplication.
For example of a possible use case, a subset of my components might all use a facility whereby they're read-only to certain people (based on roles or some other logic). I would like to be able to easily add that to any component, so some form of AccessControl Trait would be ideal.
If I then set a readonly="{{ yes|no }}" on the blade tag, the trait setter function would get called and I wouldn't need to have added a new constructor param or duplicated the code into the component class. It would all be nicely encapsulated in the Trait. Inheritance would be too rigid as multiple features may need to flow down.
I've been digging into the Service Container binding stuff, and I can't see how to make this work. It's almost like, in the build() method after it's resolved the constructor params, it could look for setter methods for any parameters it didn't use... maybe that's too simplistic...
Or, is there a way to manually register the setters as something the Container would call while resolving the component?
Or another approach that I'm missing?
Never mind - after a load of digging, I've found the 'withAttributes' call which passes any variables not in the constructor into the view in the $attributes array.
That might solve most of what I was needing - it gives me access to the variables in the blade without needing massive constructors.
Please or to participate in this conversation.