[v1] QSelect is a downgrade
-
Hello everyone,
Is it me or is it the QSelect is a downgrade for the casual use of the component?
I know that now it is more customizable, but for the casual use, older QSelect was so much easier and intuitive to use. You just put the options and that’s it.
There is a lot of props you have to remember. Filtering is a nightmare now, you need to write and mixin a simple filtering function everywhere. The filtering CSS of the field is fucked up also, input is added after the selection, and if the selection is long, then the height of the component doubles and the design of the page is distorted.
Sublabel is removed also which makes you customize every select for just a single sublabel.What thoughts do you have, guys?
-
It would be nice, if you could formulate your concerns in a more constructive manner.
Scott
-
I mean that usage is overcomplicated now. Some useful features was removed and it is left for the user to reproduce it again in favor of customizability? I am not angry or anything, I just think it is kind of messed up now.
-
@vuras form docs example
<q-select v-model="model" :options="options" label="Standard" />(simple no?), it does have a lot of api (you don’t have to use all), but you still can use it simply, and if you want an own implementation you can wrap it with the props or whatever config you want in it and use that wrapper component in your app. -
I also think that it gets too overcomplicated. 69 props, 15 slots, 13 methods… this single component has more options than almost all other form components together!
Not only too many props, but worst, a complex interaction between then… (like fill-input, use-input-hide-selected and multiple creates dozens of different behaviours)
It is amazing powerful now but drives me with overlapping functions between all behavior props.
Maybe one basic for small lists (where performance is not an issue, as QSelect now is optimized for performance (yeah
), but harder for basic use cases like a single select with filter…Another good way is to create a QSimpleSelect more simil;ar to what we had in 0.17.xx
Anyway, Quasar still one of the best pieces of software I had worked it.
-
@marcelo sudden change to this tho will introduce some breaking changes, v1 has been out for a while now. components can be extended, so you can implement a dumbdown version of QSelect.
-
@metalsadman I am not proposing any breaking changes.
Add some preconfigured wrappers around QSelect to make easy to use would be good to framework environment (of course you can do it on a project basis, but why always create a component with a basic filter just like we had on 0.17?
If these components are on top of QSelect, no breaking changes. QSelect is almost a framework by it own nowAlso, I believe is possible to create a new component (no breaking changes) just for basic use cases.
I think the idea is to give more alternatives and expand the framework, not change the great job that exists now.
-
most of the props are in qselect atm. Imo, if the proposal is just a wrapper, then no sense doing it in core, since it can be done in the devland.
-
I also think QSelect in 1.0 is somewhat a downgrade. Somehow it doesn’t behave well and is more difficult to use. It feels like 0.17 popups behaved more consistently (looked more professionally), there were options with enabling checkboxes and a relatively simple search, and the entire api was simpler to use.
It would be nice if somehow a reincarnation of 0.17 QSelect was included to 1.x under a different name (QSimpleSelect?), and I’d be even willing to pay for this feature.
