provide traditional layout for slider
-
A request:
True I can make yet another component but can quasar support the ole traditional spinner within the slider component? As far a api could be as simple as adding a boolen prop to display slider as the good ole traditional “spinner”. The props otherwise would be much the same, max min, etc.
This wouldn’t be a breaking change just an optional style prop to the slider api.
-
easy enough to use this one. Still would be good if q-slider had this spinner appearance.
https://vuejsexamples.com/a-customizable-number-input-spinner-component-for-vuejs/
-
But it’s sooo easy to make one yourself. Just use the prepend and append slots… and you can even add TouchRepeat directive on the slots (be them buttons or icons or… whatever)
-
Ok sure I can extend as I have done with select slots but with a PR you would not incorporate this? This would not be a one off (for me). Would like that added functionality as part of a quasar base form components. Slider component as is not a great one for mobile/touch (spinner with big buttons and touch repeat so much easier)
Alternatively the quasar project could make it easier to import/use project/community “extra” components. The featherjs project makes that pretty easy (like with common hooks library). Maybe this is already happening just unaware.
Like the current quasar extras maybe a quasar vetted component “extras” repo/module. Submissions would abide by some criteria and the component would be vetted by a project member or experienced community member. Then if package is installed the components therein can be loaded via quasar.conf.js just like the main component library (all, manual, auto) instead of one off in code as would be the case currently.
-
@dgk said in provide traditional layout for slider:
… Maybe this is already happening just unaware.
I believe AE (app extensions) are the way to go:
https://github.com/quasarframework/quasar-awesome/blob/master/README.md#community-app-extensionsWhy? well, quasar is opinionated at the framework level and flexible at the library level. This is where confusion comes from. Including community extensions at the core would be bad because lib level flexibility means chaos at the framework level. We could elaborate, but let’s assume that it is.
The “components” at the framework level are called “components” or “plugins” or “…”, but they really perform a role of “solutions”. You can “incarnate” those solutions and make your own “components” which are truly reusable. Just as you can have a “solution” of power engine and incarnation of this engine in a truck and a realisation of this incarnation in a truck in your garage (a final application).
We should not mix solutions with libraries with applications. App Extensions in Quasar are at this specific moment of time excellent, because they allow to quite safely extend not only visual parts of framework but also behavioral and structural parts of the whole Quasar (generator, optimizer, library, etc.). We do not know now what is “best” or is “preferred”, this will come with time and patience. BUT if we will close our understanding of Quasar ecosystem with some specific solution with our current understanding and current needs, it will surely close many future possible Quasar applications.
What we will probably should do, is to wait for the bigger ecosystem of app extensions, and let them live, divide, mutate, and from that we will know what boundaries are necessary. I opted for one for AE with many visual blocks for theme developers, you are talking about specific interactive components family for selection, others want drag’n’drop, others wants integrations with backend or auth solutions. Quasar is BIG idea and just a thought that it creates all those needs in people minds should tell us how BIG the Quasar (as a concept) really is.
