livewire: QueryString doesn't appear to support nested values.
Description
You can do;
public $name = 'test';
protected $queryString = [
'name'
];
You can’t do;
public $filters = [
'name' => 'test'
];
protected $queryString = [
'filters.name'
];
// or
protected $queryString = [
'filters' => [
'name'
]
];
You can provide filters asa whole as a query string, but it ends up being super messy, especially in a use-case such as filters for something.
Context
- Livewire version: 2.3.0
- Laravel version: 8.11.2
- Browser: Chrome
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 19
+1 for this.
Hi everyone! I figured it out.
The URI would be like this:
Of course the
filterprefix is optional, and you can omit the if-statement in__get()@calebporzio can you please add this feature? Thanks in advance!
@sathio, oh, I beg my pardon. I took a closer look at my enhanced version of this code and I saw that I initialize these filters values on boot.
Basically, you should do something like this:
Automate this thing via
$this->filters = map($this->filters)blah blah blah…Remember that
boot()method in traits is written differently, so in your case it should bebootWithFilters(): See here for more information.@sathio No, I’ve just checked it out and it works perfectly fine. After a reload it takes values from query string and then passes them to inputs via
wire:model.wire:modelworks because of my__get()magic method. Thus, that’s a working solutionyeah i think you should have a look at it ))
REOPEN 😃
Agree this is not a minor shortcoming. Without dot notation, query strings (and array props) lose so much of their potential. The viable strategies are: either don’t use queryString at all (bad), or don’t use array props for filters (better but sad). The second option clearly denies smart approaches like the one suggested in the Surge demo: