@Evan You can use different varialbles with v-if and QModal and trigger modal change before the v-if. Similar to what you did in your initial post but without the watchers, instead use the events that come with QModal. Check this Codepen
I don’t know if this would be less pain but i think it might be better than using the watchers.

You should be able to use the same variable you are using for v-model and v-if.

 <q-modal
   v-if="model"
   v-model="model"
  >
   My modal content here
 </q-modal>

I never really needed to do that, so I’m wondering why this happened with you. It’s really hard to tell without looking at your project. But some stuff that come to mind when having to render too many components at once are:

• Lazy loading your routes
• Dynamic/Async components
• Pagination
• Infinite Scrolling
• Rethinking the design if it can be done in a better way…

The best way to do this, is by installing the module from lodash that you need and not the whole library. So in your case you only need the orderby method.

1. Install lodash module using npm or yarn from inside your project root folder

   // using yarn
   yarn add lodash.orderby
   // or if using npm
   npm install lodash.orderby --save
   

2. Import the module to be used. Here you have two options.

   1.Quasar App plugins

   // using app plugins, use this way if the method is being used a lot across your app
   import orderby from 'lodash.orderby';
   
   export default ({ Vue }) => {
       // this will create the $orderBy object on the Vue instance
       // you will be able to access it with this.$orderBy or Vue.$orderBy
       Vue.prototype.$orderBy = orderby;
   }
   

   2.The other option is regular import on component level

   // inside your component you will import the method
   // either inside script tag if using .vue or at top of .js file
   import orderby from 'lodash.orderby';
   

Also if you want to use filters in vue, you can still do that. But you have to create yourself, as vue dropped builtin filters. Here is a demo on how this can be done.

Vue.filter('currencyFilter', (value) => {
   // here we are adding a comma every 3 characters
   return String(value).replace(/\B(?=(\d{3})+(?!\d))/g, ',');
});

Then inside our component we can use it as we would use normal filters.

P.S: You can create filters inside components or use quasar app plugins for that. But again this will depend on how often and how many components are going to use that filter. So, I would rather use computed properties for simple filters like the one you have or the one i gave example on, but if there’s a lot of components(>25%) using this then I would prefer a filter placed in app plugins.

Having tried both and already did the switch to Quasar. If we just want to compare common ground, then I can say Quasar is more flexible and better with performance. But I think vuetify is more popular and mature but hopefully quasar with a satable release 1.0 will have that soon. Also having looked at framework code, quasar is coded in a better way. Beside all that, quasar cli and the cross platfrom code are great. Good luck on your switch.

@korbendallas Okay now I understand what you want. You are probably using v-if on the tab and that’s why the html is not rendering. You should use v-show for this type of things that involve tab switching(this way the html will render with display none). Then the validation should work, otherwise you will have to implement that logic yourself. Also, if you want to seperate the validations you can use validation scopes and that will give you back validations in seperate errorbags for each tab.

jsfiddle/codepen would make your problem easier to solve. But I’ll try to explain as much as I understood from your small description.

You will need to validate each tab before letting the user move on to next tab which means if the fields in Tab A doesn’t validate the user will get the alerts when trying to switch Tab B and is forced to do the changes before he moves on. Finally, server side you will validate all form together(of course you have to do that anyway, cause javascript can be altered client side…)

This performance stuff is related to how vue works (MVVM libraries in general). In which they need to create an instance for every component you are trying to render in the loop and set bindings to it). This is important for vue to be reactive and update those components fast. This is a famous issue with vue and here’s a quick link from that issue on vuejs git repo, read the whole thing, it sheds the light a bit on what workarounds can be used in such cases.

In brief, if you don’t need vue’s reactivity on this part of your app then you should use something else like handlebars… Or maybe try and create statless functional components. For that you will need to create your own table components and then use them with Q-Table. (I don’t know how much that would imporve performance but is should)

I usually use chrome/firefox and record the performance while testing the part I need to test and if you’re using vue 2.2.0+ you can get advangtage of the user timing api. Here’s a link from vue.js docs on that.
By simply placing this line in your code Vue.config.performance = true, it will enable vue performance tracing. Then using chrome dev tools you can record the performance while doing your test and then go through the report generated to find the bottleneck.
Here’s a good article on that matter from medium, it can get you started. Also, you might need to read a bit about runtime performance if you haven’t used it before, it’s a very powerfull tool and can let you simulate performance on slower devices. If using chrome dev tools, here’s a quick link from their docs.
PS: There’s an extension that you can also use as well, it’s called vue performance(chrome/firefox) I haven’t used it much but It might also help.

That’s what i thought and read on docs. Haven’t used or tested the warning props but yeah good to know they are working and also checked back on the quasar releases page and they got added on v0.15.11

I haven’t used firebase before and not sure what best practices are for using firebase, but it appears you are trying to check authentication before your main component is created. Again as I have not used firebase, what I would do with a regular spa jwt is to take all auth logic and set it in an app plugin. you can read more about this in quasar docs. Then I would set another plugin for my routerHooks (utilise beforeRouteEnter to check for auth and redirect accordingly) so this would serve as an auth middleware.

To create an app plugin you need to first create a file in plugin folder either manually or using quasar cli(recommended)

// first import firebase and whatever you need
export default ({ app, router, store, Vue }) => {
  // add your code here to check for auth user and interact with store
}

Next you need to make sure you register the plugin in quasar.conf (refer to docs).

Another way this can be done is to use the preFetch feature, check it out maybe it helps.