App Extensions - one of the most ingenious and powerful of all Quasar concepts. I want to ask what is your vision about their role in the future Quasar architecture? They’re great and they’re powerful, yet they’re quite cryptic and there are not too many of them. Do you want to let devs create them more? As for now, IMHO there is a confidence gap between their docs, usage and “marketing”, so average developer could have a problems to just trust AE subsystem and learn it and create something with it. There’s no confidence, that it is a recemmended “Quasar way” of thinking.
Do you see them as a playground for wizards and when their toys mature, they should be incorporated into the Quasar core (icongenie) or rather as a system for Quasar openness and integration and also - very important - as a market (in business terms) for thousands of custom AE? If it is latter, maybe it would be a sign of confidence to just convert all existing quasar components into app extensions?

@s-molinari said in Did you get support from the Quasar Dev Team or the Community?:

… And, we only can help during or own free time, so there isn’t any SLA to answer within 24h or the like. To be honest, the attitude you seem to have about OSS and how it should be “supported” is out-of-place.

just a thought - I always believed that it is we, who has a duty to support the open source authors, help them, be kind to them and praise them - not the other way around! It is they, who give something for free, something most valuable in their life - their time. It is they, who create something instead just consume as most others. Just $0.02 here.

Scenario:
Let’s assume you are building a typical (business/product/blog) webpage with Quasar. You want it to be flexible and responsive and VERY mobile friendly and VERY big screen friendly. After a while, you realize it is very hard to achieve with Quasar. Almost impossible out of the box. In normal scenario you would use one of the thousands Bootstrap site templates, BUT, in this case you are just stubborn to use Quasar.

One piece of the puzzle is fluid typography:
https://www.madebymike.com.au/writing/fluid-type-calc-examples/
https://css-tricks.com/books/volume-i/scale-typography-screen-size/

In Quasar you could use something like this in your app.styl file:

fluid-font-size($minimumSize = 12, $maximumSize = 36, $minimumViewportWidth = 300, $maximumViewportWidth = 1600)
  font-size: 'calc(%spx + (%s - %s) * ((100vw - %spx) / (%s - %s))) !important' % ($minimumSize $maximumSize $minimumSize $minimumViewportWidth $maximumViewportWidth $minimumViewportWidth)

for num in (8..28)
  .fontsize-{num}
    fluid-font-size num (num*2+2) 300 1800

The code above will generate CSS classes fontsize-8 through fontsize-28. After that it is quite simple to use it like this:

<p class="fontsize-10"> this is content text</p>
<p class="fontsize-12"> this is caption</p>
<p class="fontsize-14"> this is header</p>
<p class="fontsize-16"> this is bigger header</p>

In similar style other CSS typography properties could be scripted (line-height etc.). I know, it is not ideal, I would strongly prefer to have something like responsive/fluid typography CSS system in Quasar itself, but for now - it just works.

@s-molinari sure, good idea!

I want to ask about drag’n’drop support in Quasar components. It would be nice to have q-tree with drag and drop, or q-table with repositioned columns and rows, or q-list which could exchange items with other components.

As a learning project I created a repo with BEX technology, as of now, it can interact with specific page, inserts some DOM and propagate events from host page to BEX, persists data between page changes, executes some privileged operations and some more stuff.

This is a learning/testing project. I would GLADLY donate this repository to Quasar devs as an example of BEX awesome technology. It is a starter of course, but it looks interesting. We as a developers alway like examples and code ready for copy/paste, so such projects will be useful.

This is the repo:

https://github.com/qyloxe/qbexlinks

In readme.md there are some questions, I think the main problem is why this doesn’t work in Firefox and how can w debug/test this on Mozilla platform. Unfortunately Chrome is better in this, there are more meaningful error messages for example. It worked in Firefox at the beginning but after changes to manifest.json and maybe in some other places it stopped working.

Firefox is important IMHO because it offers a sidebar technology for BEX. In Chrome there is no sidebar unfortunately.

All questions and comments are welcome. PR or anything on Github even more. Happy coding!

@DDP said in Drag And Drop:

Upvote for built-in draggable features, especially for lists and tables

and q-tree and q-chips…

@rstoenescu @s-molinari

Hmm, as an unfortunate author of this charming “solution”, please take my advice and do not incorporate this trick/hack at the framework level into Quasar. Yes, it looks nice in developer eyes, but it is valid only in specific situations and taking it out of the context of the whole typography would be IMHO more hurting to the image of Quasar as a CSS web pages platform.

Why?

1. Typography is about visuals, rhythm, beauty, composition. This hack is an algorithmic take on font sizes and it is linear in nature. In reality, the scaling of visuals should be non-linear and adjusted to the page purpose, specific font etc. If we will encourage designers considering Quasar as their next tool, to use linear design (at the framework level), they will laugh us off. It should be a developer decision if he wants to use linears in his specific web page.

2. Yes, it is only part of “typography” as a whole and it is rather crippled part. The more advanced take to font scaling (only) at the LIBRARY level is here:
   https://github.com/twbs/rfs
   If at the APP level, one would want to use this LIBRARY, then one would only need to:

npm install rfs --install

and in their app.styl code:

@import "../../node_modules/rfs/stylus";

Why is it encouraged to use this library and not incorporating anything into the framework? It is not recommended because you lose the ability to easily and quickly manage and update RFS as a dependency. Why is it important? Because for example “my” solution doesn’t work fully on safari browser. There are specific quirks which this library handles and my hack does not. There is a documentation of how and where use or not to use scaled fonts (not on HTML tag).

1. Why typography is so important on web pages (and even on web apps)? What is this typography anyway? Well, there are so many tutorials, books and knowledge. Those are interesting at the beginning:
   https://css-tricks.com/typography-for-developers/
   This one touches of the tip of the iceberg - rhythm:
   https://www.webfx.com/blog/web-design/css-typography-02/
   There is a beautiful parable - I’ll cite “The concept of vertical rhythm is simple: Line heights, margins, and padding should all be equal or within even proportion.”. Even if a daveloper knows how to use CSS typography properties (so many…) does she understands what rules needs to be followed and which ones could be broken?
   This is nice one too:
   https://practicaltypography.com/
   … and many more.

2. What can I do anyway? Well I’m strongly encouraging to somehow incorporate Bootstrap design concepts into Quasar, but not necessarily at the framework level, but rather as friendly agreement to “not reinvent” Quasar own solutions, in a way, which would prevent using of knowledge and solutions accumulated in Boostrap as a concept. As I said in previous posts, the key is to convince thousands of developers from Bootstrap to convert to Quasar.

3. Can I use Boostrap already in Vue and link it with Quasar? There are solutions at the Vue level for example:
   https://bootstrap-vue.js.org/
   https://medium.com/@BjornKrols/integrating-and-customising-bootstrap-4-in-vue-js-cbc29ba7688e
   But they won’t be rather compatible with Quasar, because Quasar, at the framework level, intentionally or not, is using similar CSS classes to Boostrap, and it would just make a mess if one would want to use those two CSS system at the LIBRARY level.

4. Why am I differentiate “framework”, “library” and “app” level? At the framework level there is an “inversion of control”, at the “library” level it is the “app” who decides where “control” is, and the “app” is where the “interaction” is. Without “interaction” there is only “web page”.

5. OK, so what are the options to play along with Boostrap4 in Quasar? Quasar is based on “material design” and Boostrap is not, so why we even are talking about that? Because the most important are those designers/developers to convert and thousands of web page templates and snippets to use. We do not need to USE the B4 as a base for Quasar, we only need to have “possible way” to use hard learned B4 skills in Quasar environment. It is sufficient for Quasar not to prevent this (as it is doing now). Have it be done in Vue? Yes, there is a project MDBootstrap - “Material Design with Boostrap in Vue”:
   https://mdbootstrap.com/docs/vue/
   The name is perfect, becuase this project, as it is claiming, converted 800 000 developers to using Bostrap in Vue! This is the scale of traction we are talking about.

6. How is it possible for this project to be this successful? It allowed to use B4 skills and promised to multiply the productivity by using Vue. This project is focused on presentation, which is Quasar weakness. If Quasar would incorporate some of the design elements/concepts/ideas from MDB, than because it is a superior FRAMEWORK it would just offer a win/win.

7. In essence - we really do not need to follow the path of manually dealing with every css typography property or scaling or visual specifics. It is Vue and it is 2019. The MDB project has something like “Sections”. Please take a look:
   https://mdbootstrap.com/docs/vue/sections/demo/
   This is what we (as “we” developers") need at the end of the day: the highly configurable web page compound elements, with superior layout, excellent typography, visually atractive and highly configurable sections of blog, contact, e-commerce, features, intros, magazines, projects, social, teams, testimonial, and of course, jumbotron. With those “bricks” the Quasar would not only be an excellent app platform but also web page platform. In MDB those sections are highly compatible with B4 semantics and this is why this project is so succesful at developer acquisition. In MDB they are manually converting those web templates and snippets (but it is possible and it is simple), in Quasar we just could write something to automatically convert existing B4/MDB templates/snippets (ideally of course).

8. What am I proposing? There is a concept of App Extensions in Quasar. It is just ingenious. What we need in V1 is to not overwrite CSS classes from B4 (which would allow to use some of the B4 concepts) and make an App Extension with default sections for web page developers (maybe even the same as in MDB - they’re great). There is a twist - in specific demos, there should be examples of incorporating Quasar app components in those sections! It would be just a killer feature for thousands of developers. They couldn’t resist the temptation to finally use something app centric on those boring web pages, they are making every day, just to bring some food on the table.

@rstoenescu said in fluid typography - SOLVED:

… Quasar is looking into the future and sets its own high and modern standards. And yes, in order to make progress in web development you need to break the current establishment. Otherwise we’d all be continuing to write websites in cgi-bin / perl today too, because maaany years ago that’s what developers were accustomed to. And what most developers are accustomed to at one point in time doesn’t actually mean it’s the best solution or the “definite” solution, and Quasar will never bend into choosing what we believe is not the optimal path to high quality work, not even over money.

We now have limited resources, but if you take a look at what has been achieved here then imagine what we can do with proper resources. What I want to achieve with Quasar is to raise the bar for web development as a whole. Make it go forward, evolve. Change minds. Point out when there’s a better alternative.

Please, please put above words somewhere on the main page. This is so strong, power and emotional narrative. Pure energy which leads and shows the new way to people. I’m in awe of those words, you used so many emotional and strong terms in such a short content. Almost like a poetry, but for developers Please, use those words not only on this forum but for rest of the world to hear. They deserve it.

Drag and drop in quasar with vue reactivity would be a KILLER feature.

As for now, It is not possible, or VERY hard, to embed drag and drop in quasar application without quasar support.

In example someone would like to drag and drop tree items, or other elements and mix them with lists or even other vuex objects. If you are using external library (vue-dragula is in my opinion useful somehow) then there are situations, where you just can not do some things because quasar does not let you or actively prevents you from doing this.

So, I just patiently wait for drag and drop support in quasar. (Also for a support for keyboard navigation).

Found this little gem. Thought it might be helpful to somebody:

https://instadeq.com/blog/posts/things-end-users-care-about-but-programmers-dont/

such component would strongly need some kind of autocomplete. Without that, you will end up with “vue”, “viu”, “vee”, “vui”, “wee” and 40 more mutations from different users.

@fakedrpanda yep, definitely worth watching his materials. Good catch!

@fakedrpanda If you want to use data from vuex in more advanced form, ie searching, querying, updating then i STRONGLY suggest to use this:

https://vuex-orm.org/

With this lib you can build models, those models could consume nested data and normalize them, you have excellent query capabilities and many more. In the context of q-table, you can use those queried data as computed property and this will maintains both reactivity and filtering. Meaning changes to data done via models will reflect to your data views (q-table etc.).

@sanjee
In UMD you do not need to import anything:

// global context:
console.log(Quasar.plugins.Screen)

...
     created () {
       // inside components:
       console.log(this.$q.screen)
     },

it is available as this.$q.screen inside components or as Quasar.plugins.Screen in global (window) context.

more here:

https://quasar.dev/start/umd#Quasar-Plugins

We can all agree that class-based applications are easier to test with jest than function-based ones.

we can, but do we must? that’s different…

Also showcasing big companies that use quasar could be another good option to make it more popular.

Honestly? Get any framework in history, backed by “big company” and you will see a bloated, commitee agreed, all-having monster. Frameworks/libs/technologies such as Vue, Quasar are created in spite of those “big companies” monstrosities. Do you think that Google/Facebook backed Quasar would be such elegant and well designed? Think again, this time with those history examples.

PS: Quasar Team: Please take into account that jwt is old and should the replaced by paseto as state here

paseto will be old, too. As any other “security” technology. The “security” part you are talking about is strongly orthogonal to Quasar/Vue from architectural point of view. Therefore, choosing “one, and one only” security integration at the framework level would be just “stupid”. Yet, the Quasar and Vue are “wise”, “well thought”, “elegant”, because they allow different integrations. Those integations are at different level of abstractions. For example you could argue, that there is one and only valid video player. Any of those “currently” best “security” technologies just comes and goes.

@wpq

QTable API - scoped slots:

overloading slots:

• body
• body-cell

complementary slots:

• body-cell-[name]

Maybe this will help to build a better mental model of q-table. BUT bear in mind, that in the context of row, the body-cell-[name] are complementary, but in the context of cells they’are of course overloading. Nevertheless, the data model of q-table is: “collection of rows”, so I am used to think about them as I wrote above.

@wpq you didn’t wrote about your expected workflow, yet.

Such components are possible to run in exact or similar way in many web IDEs. Start here:

https://quasar.dev/start/playground#Codesandbox-Template

BUT if this is a best or preferred way of BUILDING apps or TESTING apps or CHECKING app I don’t know, because you still didn’t wrote WHY and WHAT do you want to achieve (and not, editing single component in browser is not a fiinal goal - it is just one of many ways to achieve a bigger goal) ?

@wpq hmmm, Quasar docs always worked with online sandbox. For example buttons:

https://quasar.dev/vue-components/button

Just click here:

And you will go here:

https://codepen.io/pen/?&editable=true&editors=101=https%3A%2F%2Fquasar.dev%2Fvue-components%2Fbutton

And see that:

Works great…

@wpq yeah, I admit I still do not understand your use case anyway, in case of “running shared code” you can also check those nice web IDEs like:

https://jsfiddle.net/

there is excellent codepen:

https://codepen.io/

If you mean something more like online collaboration, then there is such an early option in vsc:

https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack

Well, it could be more helpful, if you would just describe in bullet points what is your preferred/imagined/dreamed workflow, who does what, who has access to where etc. There are tons of possibile solutions.

@wpq github has private repositories and private organisations. The colaborator could clone your repo, build it yourself, debug, work and then just make a commit or pull request depending on your workflow.