One slight disadvantage I found with using extends vs the solution I described initially above is that if you’re using an IDE, you lose autocomplete for component props, at least IntelliJ family editors. For example if I do

<q-input
   err<tab>

The editor will suggest the error-message, error and no-error-icon props, but when using my-input, I don’t get these suggestions. This could work in principle, but the Vue plugin for IntelliJ apparently doesn’t understand extends.

@dobbel I’m not sure I understand the Stackoverflow guy’s objections. I just tested out extends and it works. It may be true that you can’t “extend” the template code, so it doesn’t exactly correspond to subclassing in an OO language, which seems to be the Stackoverlow guy’s objection, but that seems like a fairly pedantic objection IMO. Extending solves the problem in this case. I just tested this and it works as expected:

// MyInput.vue
<script>
import { QInput } from 'quasar'

export default {
  name: 'MyInput',
  extends: QInput,
  props: {
    outlined: {
      default: true
    },
    dense: {
      default: true
    }
  }
}
</script>

I can use my-input just like q-input, and it supports the same props, events, slots, and methods. The only difference is outlined and dense default to true.

It was just pointed out to me in another thread that you can actually extend Vue components instead of wrapping them, which I think solves most of my concerns with wrapping. https://forum.quasar-framework.org/post/21630

Basically, instead of writing a wrapper like above, use extends like this:

<script>
import QInput from 'quasar'
export default {
  name: 'MyInput',
  extends: QInput
  props: {
    outlined: {
      type: Boolean,
      default: true
    },
    dense: {
      type: Boolean,
      default: true
    }
  }
 }
</script>

@jraez Thank you! I didn’t know about extend. That’s exactly what I wanted.

Just to help anyone finding this thread who wants the solution, I just tried @metalsadman’s solution for writing a QInput wrapper. This worked fine for a wrapper that overrides the outlined and dense props but otherwise has the same API as QInput.

<template>
  <q-input
    v-bind="attrs"
    v-on="$listeners">
    <template v-for="(_, slot) of $scopedSlots" v-slot:[slot]="scope">
      <slot :name="slot" v-bind="scope"/>
    </template>
  </q-input>
</template>

<script>
export default {
  name: 'MyInput',
  computed: {
    attrs () {
      return {
        // Put any prop value overrides here, before the ...this.$attrs line
        outlined: true,
        dense: true,
        ...this.$attrs
      }
    }
  }
}
</script>

@metalsadman Thanks for that. That’s closer to a transparent wrapper than I realized was easily possible. That still leaves out methods, but it’s much less common for me to want to call methods on components anyway, so that’s not a big deal.

I still prefer my solution of just using the Quasar components directly rather than having to write wrappers for everything though. It seems to me that it would be the rule rather than the exception to want to override the default style props for form components in a consistent way throughout an application. Expecting every app developer to write their own wrapper components to solve this problem seems like a clunky solution, especially since there’s no standardized way to do that, so every developer is going to end up doing it slightly differently.

@jraez As I mentioned in my post, I am aware of the recommendation to wrap components. However I think that is an overly heavyweight solution when you just want to override some prop defaults. Let me work through an example to demonstrate why.

Say I want to make it so in my app, QInput components default to having the outlined and dense properties set to true. Let me specify the requirements I have for my modified QInput.

• The outlined and dense props should default to true
• It accepts all the same props as QInput
• It emits all the same events as QInput
• It has all the same slots as QInput
• It has all the same methods as QInput

Basically, I want the exact same API as QInput, but just with some different prop defaults. The first two of these requirements are easy to implement. Something like this would work.

<template>
   <q-input
     v-bind="$attrs"
    :outlined="outlined"
    :dense="dense"
  />
</template>

<script>
export default {
  name: 'MyInput',
  props: {
    outlined: {
      type: Boolean,
      default: true
    },
    dense: {
      type: Boolean,
      default: true
    }
  }
}
</script>

The v-bind="$attrs" line is all it takes to make my wrapper component accept all the same props as q-input. However there is no equivalent easy way to forward all events, slots and methods to the wrapped component. So in practice I’m probably going to compromise on my ideal requirements, and only add slots, events and methods to my wrapper as I run into a need for them. This adds extra work and provides a less ideal experience than if I could use the Quasar components directly.

To be clear, I’m all for writing wrapper components for cases where I actually want to significantly alter or enhance the functionality of a component. I just found that wanting to use vanilla components, just with different defaults for some props, was a common use case for me, especially since Quasar uses props for a lot of the visual configuration of components. For these cases wrapping seems like overkill.

I’d like to propose adding the ability to configure default prop values for components, possibly in quasar.conf.js. This would especially be useful for style props. For example in my app I might want QInput components to default to outlined and dense. Since Quasar uses props instead of CSS classes for a lot of style customization, there isn’t an equivalent of an application-wide CSS file to configure these defaults. The current solution I’ve seen recommended a couple of times on this forum is to write wrappers for components that override the defaults, but in my opinion this is an overly heavyweight solution when all you want to do is override some prop defaults.

I’d like to propose a componentDefaults section in quasar.conf.js, where you could put things like:

// quasar.conf.js
...
    componentDefaults: {
      // Override QInput default prop values
      input: {
        outlined: true,
        dense: true
      },
      // Override QBtn default prop values
      btn: {
        flat: true,
        class: ['bg-primary', 'text-white']
      }
      // ... etc for any other components you want to customize
    }

This configuration object would be made available to Quasar components. The idea would be that components could have a hard-coded default prop value, which can be overridden by the component configuration, which in turn is overridden by explicitly passed in props. I can imagine it might not make sense to allow all props to be configured this way, but it certainly seems to make sense for the style-related props.

I recently ran into the same issue, of wanting to impose consistent style options with multiple Quasar component types throughout my app. For example I might want q-input components to default to dense and outlined, and q-btn components to default to dense and flat. Since Quasar components use props for configuring many aspects of components, you can’t just use CSS for this.

I tried the approach mentioned above of wrapping components, but found this to be problematic. To use QInput as an example, what I really want is a component with the same API as QInput, including the same props, events, slots and methods, but just with different defaults for some of the props.
To achieve this by wrapping I would have to make my wrapper forward all of these things to the wrapped component. For props this is simple using v-bind="$attrs" like this:

// MyInput
<template>
  <q-input v-bind="$attrs" .../>
...

However I’m not aware of an equivalently trivial method for forwarding all events, slots and methods to the wrapped component. This means when I write a wrapper, I have to choose between either doing a non-trivial amount of work, or not replicating the API of the wrapped component. For simple components like QInput this might still not be a big deal, but it adds up when I start wanting to do the same thing for multiple components, and especially for complex components like QTable.

The approach I came up with instead was to create a defaults.js file with an object for each component I want to customize, like this:

// defaults.js

// default prop values for QInput
export const inputDefaults = {
  outlined: true,
  dense: true
}

// default prop values for QBtn
export const btnDefaults = {
  flat: true
}

// .. Etc for any other components you want to customize

To make it easy to access these defaults I make a boot file like this:

import * as defaults from 'src/defaults'

export default async ({ Vue }) => {
  Vue.prototype.$defs = defaults
}

Now in templates I can make a component use the defaults simply by adding a v-bind="$defs.componentTypeDefaults" attribute, like:

<template>
  <div>
    <q-input 
      v-bind="$defs.inputDefaults"
      label="The Label"
      ... other props
    />

    <q-btn
      v-bind="$defs.btnDefaults"
      ... other props
    />
  </div>
</template>

It’s not quite as convenient to use as custom wrapper components, but on the other hand it’s much easier to customize a large number of components, and I’m not losing access to any of the functionality of the Quasar components. I still have access to all the events, slots and methods of the Quasar components without having to explicitly forward them in my wrappers.

What I wish for is that Quasar would add this functionality so that component prop defaults could be configured in quasar.conf.js. I’d like for there to be a componentDefaults section in quasar.conf.js that allows configuring component defaults just like I’m doing in defaults.js.

Answering my own question. I found quasar-ide-helper, which solves this problem. However it seemed to do a bunch of other stuff to my project that I didn’t want or need. In one of the issues for that project I found this solution.

Make this change to your quasar.conf.js.

At the top add

let fs = require('fs')

Then in the extendWebpack function, add:

        if (!fs.existsSync('webpack.config.js')) {
          fs.writeFileSync('webpack.config.js', `
/* eslint-disable */
/**
 * DON'T EDIT THIS FILE!!
 *
 * This file is generated to help IntelliJ resolve Webpack aliases. It is never run in the app.
 * If you need to extend your webpack config, put your code in quasar.conf.js into extendWebpack function
 */
module.exports = ${JSON.stringify(cfg, null, 2)}
`)
        }

You’ll need to run quasar dev or quasar build to trigger this code to be run. Now you can configure the IDE to use “<project_dir>/webpack.config.js” as the webpack config, and it’ll know about your aliases. If you want to update the file because your webpack config has changed, just delete it and re-run quasar dev.