There isn’t an official or “curated” Vue HTTP library for some time, as Vue team now understands that it wouldn’t fill any role that a third-party library like Axios couldn’t.

However, maybe you were searching for something like this? https://github.com/huanleguang/v-model

@dgk It seems that it’s being exposed in the parent element, you only need to add !important clause.
https://codepen.io/anon/pen/jzGMZE

@a47ae In this case, I’m not sure if this.$config would be reactive (what means creating extra listeners) or not.

I think that a more Vue-centric solution would be registering a Vue mixin, either globally (you may need an app plugin for it) or locally.

Example (global):

Vue.mixin({
    foo: {
        bar: 'baz'
    }
})

Then access it as this.$options.foo.bar (please notice that vm.$options.* is not reactive).

They are not colors from HTML/CSS, they are colors from Quasar Color Palette, that’s itself based on Material Design palette.

Notice that you can add your custom colors. While Vue doesn’t re-introduce style interpolations, using v-bind:style accordingly should probably work (I haven’t tried).

The Quasar demo app, presented in the docs, is located here. It’s supposed to be a comprehensive showcase of all Quasar components, not a demo like TodoMVC, though.

Answering your other question: the components are defined in the JS files themselves. But, instead of using <template> tags, it uses render functions (see Vue docs about render functions).

More details: https://vue-loader.vuejs.org/en/features/scoped-css.html

@mesqueeb

The first mixin with the fluid font-size etc. Is it possible that it doesn’t work well with setting some height to vh?

Your problem may be related to an issue where some browsers doesn’t allow vh and vw values inside calc() expressions.

(what about rem and em?)

It should work as expected, as my mixin and the one you provided in Sass should output the same on a demo using em. If the outputs are different, let me know.

@celtic said in Themeing, Stylus vs SCSS:

You are using the exotic css-preprocessor stylus, why this?!? I wasnt able to figure out any advantages by using this instead of SASS and migrating all our SASS universe might not be an option. We got booted because of this decision

1. Nothing stops you from using Sass on your Quasar projects (see docs). The only con is that you won’t have access to Quasar internal variables (if you’re reusing your views, you probably won’t need them).
2. Stylus is not exotic at all: it’s the most popular preprocessor after Sass and Less, and arguably more flexible and expressive than first two. Another advantage is that Stylus is written in Node, while Sass is written in Ruby (therefore requiring an additional dependence). So, when Quasar started, years ago, Stylus was probably the boldest choice – now, that it isn’t in active maintenance anymore, it’s not such a future-proof choice.

@benoitranque If I remark correctly, the padding was there for the case when scrollbar was needed.