Computed property dependency injection #6967
gbuckingham89
started this conversation in
4. General
Replies: 1 comment 2 replies
-
|
Surprising this isn't getting more votes, came across this also while migrating an application... |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
I submitted a Pull Request |
Beta Was this translation helpful? Give feedback.
-
|
Find myself with the same problem, in the end did something like this ... class Foo extends Component
{
public $my_list_of_stuff = [];
#[Computed]
public function computedFilteredListOfStuff()
{
.... // Filtered my_list_of_stuff here using input from a form
}
// Used repository to get list of stuff ...
public function refreshListUsingRepository(MyRepository $my_repository)
{
$this->my_list_of_stuff = $my_repository->all();
}
} |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm just upgrading a Laravel app that has several Livewire components from Livewire v2 to Livewire v3 and have stumbled into a problem with dependency injection with computed properties.
In v2, it was possible to inject dependencies into the computed property methods;
In v3, the recommended way to define computed properties is now via attributes;
If I define an argument that is resolvable via the container, I get an exception;
The v2 method of defining computed properties does still work in v3, but this means I'm ending up with a mix of old (so I can keep the DI) and new (following current documentation) style definitions - which is inconsistent.
I haven't labelled this a "bug" because I can't see the use of DI in computed properties included in the documentation for v2 or v3.
Beta Was this translation helpful? Give feedback.
All reactions