These are features of babel/eslint/etc., not quasar. We can always put some configs in package.json like this:

  "babel": {
    "presets": [
      [
        "@babel/preset-env",
        {
          "targets": {
            "node": "8.11"
          }
        }
      ]
    ]
  },
  "prettier": {
    "printWidth": 120,
    "trailingComma": "all",
    "singleQuote": true,
    "semi": false
  },
  "eslintIgnore": [],
  "eslintConfig": {
    "root": true,
    "parserOptions": {
      "parser": "babel-eslint"
    },
    "env": {
      "es6": true,
      "commonjs": true,
      "node": true,
      "browser": false
    },
}
...

Sometimes we don’t want ripple effects for certain compnents which are by default with ripple. Is there a way to specifically disable ripple effects for a certain QBtn\ QCollasible or so?

Sorry for the delay. Didn’t have Internet connection for the last few days.

When running a Quasar app on a lower-end mobile device (like a smart phone produced 5 years ago…), ripple effect always causes considerable lag. That’s why I am considering disabling it.

Is there an option to let $q.dialog return a promise like it did in 0.17+ ? It is awkward to convert callbacks to promises and fit in the promise or async/await codes every time we use dialog.

Is there an option to let $q.dialog return a promise like it did in 0.17+ ? It is awkward to convert callbacks to promises and fit in the promise or async/await codes every time we use dialog.

These are features of babel/eslint/etc., not quasar. We can always put some configs in package.json like this:

  "babel": {
    "presets": [
      [
        "@babel/preset-env",
        {
          "targets": {
            "node": "8.11"
          }
        }
      ]
    ]
  },
  "prettier": {
    "printWidth": 120,
    "trailingComma": "all",
    "singleQuote": true,
    "semi": false
  },
  "eslintIgnore": [],
  "eslintConfig": {
    "root": true,
    "parserOptions": {
      "parser": "babel-eslint"
    },
    "env": {
      "es6": true,
      "commonjs": true,
      "node": true,
      "browser": false
    },
}
...

I found in quasar-cli/lib/build/app-path.js:

const
  appDir = getAppDir(),
  cliDir = resolve(__dirname, '../..'),
  srcDir = resolve(appDir, 'src'),
  pwaDir = resolve(appDir, 'src-pwa'),
  cordovaDir = resolve(appDir, 'src-cordova'),
  electronDir = resolve(appDir, 'src-electron')

Does this mean the src path cannot be changed?

for both dev server and build?

Many components in 0.15 use v-model to control show/hide status. By using v-model the data can be changed either from inside the component itself, or from outside. This is a much better way compared with the old way like $ref.xxx.closeLeft() in 0.14. However, v-model has two drawbacks:

1. one component could has only one v-model, so if the component needs two or more double-directional synced props, it does not work (for example, for now QLayoutDrawer uses v-model since it needs only one prop to control show/hide status – but who knows when in the future it would need more… );

2. v-model has no declarative name for the prop, so it is hard to understand what the v-model is for at the first glance, without referring to the documents.

In fact , :prop.sync can do the same thing. A component can have multiple .sync props, and .sync also give the prop a name to explicitly show what this prop is for. We see QTree and QTable are already using .sync props. Maybe it is worth discussing if we should make more use of .sync rather than v-model, say, just turn this:

<q-layout-drawer v-model="isLeftDrawerShowing">

to this:

<q-layout-drawer :show.sync="isLeftDrawerShowing">

Glad to see in 0.15 many async callback functions have been made to promises, which extremely facilitate the usage of the new async/await syntax.

However I noticed that there are still a few components using done()/fail() callbacks (such as QUpload, QPullToRefresh, QAutocomplete). It would be super nice to make them all promises.

In 0.14 when using history mode of vue router, quasar alerts that the history mode is not working with cordova. Is this still the case in 0.15+ (since I don’t see the same alert in 0.15)?

Amazing~!

use import instead of require, or use require('xxx.vue').default

2.5.0 doesn’t fix this bug yet.