Select options get irrelevant results in the drop down list
Hello,
When using Select::make() with ->options() and ->searchable(), the search works instantly but sometimes shows irrelevant results because filtering happens client-side.
When switching to ->getSearchResultsUsing(), the results are accurate (server-side filtering) but the search becomes noticeably slower.
In my case, the dataset is very small (about 50 records per tenant), so I’d expect client-side searching to be both fast and accurate. Is this expected behavior, or should ->searchable() filter results the same way as ->getSearchResultsUsing() even when using ->options()?
Please let me know how to fix this, Thank you
Here is the code I am using:
65 Replies
bump
It doesn't really matter clientside or not, what's different about the name? what if you set driver_id to be a relationship and adjust the relationship option? what about ->preload() too if you only hvae 50 items just load them all.
@toeknee the issue is for example I have 10 names, this drop-down is being used in the filters so I can't use the relationship here.
"John Smith"
"Meghan Stacey"
"Nicole"
"David Smith"
and so on
when I search -> john it displays john smith on top but it shows the others which are totally irrelevant with the search term.
If we look at how select2 works it only shows the matching option.
Client is comparing it with select2 and wants me to fix it because they usually copy paste names to search in that list and just press enter to select, because they have really busy business hours and he want it to work really fast.
I would really be grateful if someone could help me fix this issue, thank you so much.
Here is the example with the issue
bump
Ahh it's a filter, that is a strange search look at the query with debugbar or telescope
@toeknee the results are preloaded and I am not using getSearchResults method so the searches are simply client side, there are no queries, do you think debugbar or telescope will read that ?
preloaded will still show you the queries on that page you just need to open the request on that page
the query is running fine and has the data in the drop down which are supposed to be there, but the issue is when I am searching it should only display the matching results as you can see in the screenshot above, it shows some unmatched results too.
So if you are searching you need to see what the query is doing in the search for it to return non-matched results.
That should be shown in debugbar or telescope.
Ok thank you so much, I will try again.
@toeknee there were no queries except for the dropdown list to be preloaded once then there are no more queries for the drop down.
bump
Select::make("driver_id")
->label("Drivers")
->options(Filament::getTenant()->drivers()->orderBy('name')-pluck("name", "id"))
->searchable(),
Try this if it is working
Hello @DSM, thank you for the reply.
It is same response with a few irrelevant options.
if you are using this in filters use SelectFilter instead of Select with relationship, relationship in filter will work with SelectFilter properly
like
SelectFilter::make('driver_id')
->relationship('drivers', 'name')
->searchable()
->preload()
->multiple()
Hi that sounds good, let me check.
@DSM they are actually supposed to be form component because table filter can't be used inside Filter::form()
Where are you using the select? And is driver actually a relationship on the resource’s model?
Yes @awcodes it is a DriverPaymentResource, please check the screenshot. I am using filter form
Btw I checked the search with Checkboxlist and it works correctly matching Jo to Johny Wick and Josephine properly but when I search on Select drop down it shows johny wick along with other irrelevant options unless I type the name in full
driver_payments belongs to drivers yes
Hmm, I wonder if there is a problem with trying to use a single Filter object as a form of multiple filters? Ie is it creating a query conflict at a lower level?
well I can see the same issue in the single form as well it is same with Filter or a normal form.
this is also a relationship in the booking form
Can you try DSM’s solution with a Select instead of a SelectFilter?
ok let me try that now
Ie, if it’s a relationship you should define it as such instead of using ->options()
Well it shouldn't be using relationship though because this is a table filter which has multiple records.
Filament\Support\Services\RelationshipJoiner::prepareQueryForNoConstraints(): Argument #1 ($relationship) must be of type Illuminate\Database\Eloquent\Relations\Relation, null given, called in
But you’re trying to filter on a relationship.
that Edit modal has relationship it can work on that modal, but not where I actually want to fix this.
also the relationship will make queries to the database which kind of works anyway by using getSearchResultUsing but my client wants to only filter the driver names from the preloaded items so it is fast and works client side
Checkboxlist searches without querying same should be the behavior of Select as well to match exactly what is being searched
Then don’t use the ‘driver_id’ as the make of the select. Make it something that doesn’t exist and define all the search and labels manually.
that could work
let me try.
Just think you are trying to use convention and override it at the same time.
But the convention should work. The only thing that would slow it down would be a slow connection or a unoptimized db.
driver_id is just being used by the filters though, there is no database connection
But driver is a relationship? Correct?
Yes it is but it doesn't work with relatoinship, let me show the error.
If it doesn’t work with the relationship, then my guess is that the relationship definition is off somewhere.
the driver is the relationship it brings the results which we desire when we use the relationship but it actually queries the database which actually takes some time to search and that is what my client doesn't want
he wants to compare it with how the select2 library works.
yes the relationship definition was wrongly used it was supposed to be driver instead of drivers
but it brings the results now after querying the database.
Ok, but that’s not feasible. It should query the db. If you have 10k drivers loading all that into js memory is going to create more problems. So, at that point any slowness is at the network latency level or unoptimized db tables.
we are not going to have more than 10 or 15 drivers
If you hard code the ->options() as a test, does the searchable() work as expected?
this works fine with CheckboxList, but not with Select
Great, but we’re worried about selects at the moment.
CheckboxList doesn’t use select.js. I’m trying to isolate the problem.
I also tried the search with quotes and it worked exactly how I want it to work without quotes
Ok, just trying to reason if it’s an issue in select.js. If it is then filament can’t solve that.
Yes, I hope it can be fixed, my client keeps asking me why I haven't fixed it yet and it is difficult to explain to him about the issue.
May I know the source for select.js ? is it select2 or some other library please?
My bad, it’s choices.js not select.js
Ok thank you
it is actually the issue with the source
doing matches like fulltext
GitHub
Search results (filter) are incorrect · Issue #1165 · Choices-js/...
Describe the bug I know that this library is not maintained, but hopefully someone knows what is going on here. Take a look at this: I have Choices setup pretty simply: const choices = new Choices(...
found the issue, hopefully this will solve if we can somehow have an option to change the threshold to 0
@awcodes I changed the threshold manually in select.js to 0 and it works like a charm, please let me know how can I prevent overwriting the select.js file with future updates unless there is an important update ?
Glad you found it. From the filament pov it would require a PR to allow setting the threshold and passing that to the choices.js alpine initialization. Should be doable.
I am sorry but I am not much familiar with github and PR stuff, does it require posting a repository or the project files? or is it just a request?
There should be a contributing guide on the github repo.
Great, thank you so much for your help, I will try it.
But you could also submit it as an issue with a reproduction repo. But that will take longer than submitting an actual fix.
The contributing part actually has to have a solution to be merged right ?
Yes. That’s what PRs are. They are solutions in the code to existing problems that if merged in will fix the issues.
I wish I knew how to dynamically add the threshold value to select.js to have the solution for PR
I can simply edit the file and post it but that is not a solution
Basically, you fork the existing code on the branch you need, in this case 3.x. You make the changes that solve the issue, then make a PR from your fork.
If you’re not comfortable doing a PR then I would recommend going down the issue reporting path. It’ll just probably take longer to get resolved.
I am just confused doing the PR with edited select.js file or to have an option with config for Select component to set the threshold ? I just want to clarify this then I will definitely post the PR
I’m not sure how to explain the steps in text. But you’d need a method on the select php component, then pass that call to the select alpine component and use it in the initialization of choices js.
It’s really not as complicated as it sounds, I just can’t vocalize it.
Source dive the code and see how other settings are being passed.
I will try it, thank you so much for your time, I really appreciate it.
@awcodes I actually created a select-override.js file and extended the Select component to load select-override.js instead of select.js and it worked great.
Awesome. If it works then I’m happy for you. Good job.
Thank you so much for the guidance.
No worries.