I’m wondering if anyone has run into a situation where font-awesome icons not being decoded by the browser when deploying the application to AWS with a CloudFont/API Gateway stack. I’ve tried various things, like modifyng the BinaryMediaTypes and such, but couldn’t get anything working.

For the time being, I’ve disabled letting Quasar manage font-awesome (by removing fontawesome from the ‘extras’ in the quasar config), and just threw up a link to the font-awesome js in the index.template.html.

The documentation mentions that you have access to the ssrContext in two places, preFetch and plugins. However, I’ve noticed a third place:

export default function (/* { ssrContext } */) {
const Store = new Vuex.Store({
modules: {
example,
}
});

return Store
}

So, I’m just curious… What’s an example of how one might make use of ssrContext there?

So if I understand correctly, this is just a windows things? I can continue using npm on linux?

Reviewing the Material Design specs, this type of dialog is what’s known as a Simple Dialog.

Simple dialogs without actions
Simple dialogs allow users to act on selected elements, without action text. For example, users can simply select a list item to take action on it.

I think a good future enhancement would be if we could pass a bool (probably named ‘simple’) to convert to/from a Simple Dialog

What if the user opens the dialog, but then decides not to make a change? I’d still think that clicking outside the dialog would suffice, but that’d be problematic for a full screen dialog. Unless clicking on the already-selected date would also close the dialog… not the most UX friendly.

QSlideItem is one of my favorite additions. Something that’s common in most mobile applications, yet rare to find that feature in component frameworks. I’ve even considered switching to the iconic framework just for that feature alone.

Sure. I’m not advocating that Quasar support pre-rendering, I rarely build apps that are simple enough to be pre-rendered. I just noticed the confusion and wanted to clear that up.

With that being said, There is integration with Nuxt on the quasar roadmap for v1.0
“Alternative to Quasar SSR: Nuxt module (for ability to use Quasar + Nuxt)”
I kind of assumed that’s what it was for (to leverage Nuxt pre-rendering in your Quasar app), because I don’t know of any other advantage of introducing that integration…

@s-molinari
@pinalbhatt is talking about SPA pre-rendering. Nuxt supports both SSR and pre-rendering. Quasar (currently) only supports SSR
https://nuxtjs.org/guide/#static-generated-pre-rendering-

I think you’re confusing the terms “framework” and “library”. I don’t think anyone was advocating mixing together frameworks. That would be a bit… crazy. But utilizing libraries is a very different thing. And not to get off topic, but vue-sticky does not have the desired features.

I’d just like to add that it’s not necessarily a bad thing to mix direct dom manipulating components/widgets into your Vue app, as long you understand the potential problems and can verify that those components won’t cause such problems. The only thing you need to be careful about are situations in which both Vue and the non-Vue stuff are trying to update the same pieces of dom. When that happens, they’ll each overwrite each other’s changes because neither are aware of what the other is doing. But in many cases, the non-vue components (such as some jquery components) ‘own’ the sections of dom that are rendering that particular component, particularly if they’re configured to execute in Vue’s mounted hook, when Vue is done doing its thing for that render cycle, then they’re not stepping on each others toes.

For example, I’ve used utilities like stickybits in more than a few Vue apps to aid in sticky positioned elements. StickyBits works by directly manipulating the dom and adding/removing classes to targeted elements. It’s completely safe to do so, so as long as you’re utilizing things like that in a Vue safe way. My point is, although there is a difference between vue rendered components and vue safe components, limiting yourself to only vue rendered components might unnecessarily prevent you from taking advantage of a vast library of useful stuff out there.

This appears to have been fixed with https://github.com/quasarframework/quasar-cli/issues/173. With that change, it appears that parent preFetches (such as those in App.vue) are fully resolved before child preFetches.

The documentation mentions that you have access to the ssrContext in two places, preFetch and plugins. However, I’ve noticed a third place:

export default function (/* { ssrContext } */) {
const Store = new Vuex.Store({
modules: {
example,
}
});

return Store
}

So, I’m just curious… What’s an example of how one might make use of ssrContext there?