QSelect: improve autocomplete

[1001v]

Describe the solution you'd like Hello. I believe that developers would like to use the autocomplete in each select, where there are a lot of options. However, all possibilities for autocomplete usage i found are useless in a real app. Here some issues: 1) The doc suggests to use a filter function. I believe, that there must be a default function for filtering inside the qselect, because in most cases that would be enough. 2) The worst thing about handling filtering outside is that you have to override qselect options yourself. This approach creates issues:

• What if my options come from vuex? I have to create mutations
• What if i use multiple qselects in a component? I have to handle this logic for each of them: custom filter, custom filtered options etc. Even if i create one universal filter, i must pass an argument to it so it could override appropriate options.

Describe alternatives you've considered I've tried to wrap q-select to a new component, so it could handle this logic internally, but since there's no way to access input value (via sync property or somehow), i can't really do it properly. Also there will be some issues with typescript, if i override options in my component, due to dynamic content of options.

Thanks for your time.

[pdanpdan]

Why would you need mutations? What is wrong with computed properties. And you don't even need multiple computed properties and filter functions: https://codepen.io/pdanpdan/pen/KKpygdd?editors=1010

You can even extract the search (data) computed and the method in a mixin and you are good to go.

[1001v]

@pdanpdan i'm sorry, but your example is absolutely useless. You just ignored everything i've had written.

[luishgp]

@pdanpdan This example does not solve half of the problems presented.

In a form, I have 8 selects. The solutions I have are:

1 - Create 8 computed properties and 8 research variables; 2 - Create 8 filter functions; 3 - Create a universal filter passing the options as parameters;

All this for a simple filter on labels ...

The external filter should only be used in extreme cases, as an exception, not as a rule.

[1001v]

Also you need to use a bunch of options on each of 8 qselects to achive autocomplete behavior.

[pdanpdan]

Or you can spend 10 minutes and create a customized component that does exactly what you want

[1001v]

@pdanpdan and keep this component in each project. Great. Framework should solve this problem and keep frequently used components for you, isn't it? Or do you want to say, that autocomplete is a rare thing?

[webnoob]

@1001v A framework provides the components required for a developer to do their job effectively. If we catered for every single need for every single developer, you'd have a bloated and hard to manage framework. Instead Quasar gives you the core components you need.

Make an App Extension and you can share your component between all your projects.

You have the tools - use them.

Also, lose the attitude. You're getting Quasar for free.

[1001v]

@webnoob, autocomplete is a very common thing and presents in each framework i've ever seen. I can't understand how it can not be a core component.

Do i need to pay money and then you won't close all feature requests automatically and will actually follow all that beautiful words about meaning of the community? I always try to be as much polite as i can. But you aren't polite when you just close issues, which at least deserve some discussion.

I understand that you can't follow each feature request you have, but then just say so. "We do not want to do as you say" or "this approach doesn't follow our vision". Again: that's okay and i can get it. But please, don't pretend that this problem can be solved by the approach posted above. There're arguments here, why this is not so.

Thank you.

[luishgp]

For me, a default autocomplete is essential, and an external filter would only be used in extreme cases, where the search must be carried out on multiple object keys.

but, ok... :confused:

[Elvirarp92]

Bumping this again to agree with the posters who consider a default q-autocomplete component to be essential. Could we make our our wrapper components? Sure, we could. But autocompletes are very common and it baffles me that we have to reinvent the wheel individually, particularly when most frameworks and component libraries include their own autocomplete components.

The "we can't cater to each and every need" argument would hold water if this was a niche thing. But autocompletes are a very common pattern.

[pdanpdan]

It is niche - in what are you searching (do you use an object, a simple string, ...), case sensitive/insensitive, search from start or anywhere - you already need a function that has at least 6 branches

[Elvirarp92]

Yeah, I think I understand your perspective. You're saying that accounting for every scenario can result in a bloated component, while my argument hinges in the ubiquity of autocompletes as an UX pattern. So, we're arguing about different things, in a way.

A cursory googling doesn't show me app extensions for autocomplete components, which I find surprising. There's this, but it's for v1 of Quasar and hasn't been touched in a year. I might give it a shot.

[Zack-Heisnberg]

I rly agree also it's terrible performance as it is, I a M using for loop instead work much faster and eosnt lag on mobile