The value you store in your component property multiSelect should be an array of the selectable values you want to be checked:

For example (following your data set):

this.multiSelect = ['x-b', 'rt-builder', 'max']

Whereas for “simple” select fields (single choice)

<q-select ... v-model="selectedValue" :options="options" />

you simply do

this.selectedValue = 'identifier'

Answered here too:
https://stackoverflow.com/questions/47035330/editing-the-selected-option-in-the-select-dropdownq-select-of-quasar-framewor/48227687#48227687

Hello,

I have a Quasar-based project using Cordova mode to build hybrid app for Android and iOS.

Since end of august, when submitting an app update to the App Store, I get this warning:

ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs .
See https://developer.apple.com/documentation/uikit/uiwebview for more information.

I’ve then tried to switch to WKWebView (as suggested everywhere I could search), using cordova-plugin-wkwebview-engine.

However, I couldn’t make it work due to a blocking problem with a cookie-based authentication to a REST API server: cookies were not stored by the app anymore.

Furthermore, it seems that until cordova-ios 6.0 is released, some references to UIWebView will still remain in cordova-ios, which could lead to app rejection by Apple.
By reading cordova-ios discussions, it’s not even clear if cordova-ios 6.0 will be released before Apple decides to reject submissions referencing UIWebView, since no estimated date is available for both events.

OTOH, Capacitor seems a very interesting option: this blog article from Ionic states:

On September 4th, 2019, the Ionic team shipped a new Capacitor release […] that removed references to UIWebView.

BTW it seems to bring many nice improvements compared to Cordova’s approach.

However, the problem with failing cookie-based auth still remains.

It looks like that I have to adapt the app & its REST API to use a “non-cookie-based” authentication, like JWT.

Is anyone struggling with the same issues?

Is this path (using Capacitor + JWT) a good way to go?

I’ve created an issue here: https://github.com/quasarframework/quasar-cli/issues/194

Hello,

I have a Quasar-based project using Cordova mode to build hybrid app for Android and iOS.

Since end of august, when submitting an app update to the App Store, I get this warning:

ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs .
See https://developer.apple.com/documentation/uikit/uiwebview for more information.

I’ve then tried to switch to WKWebView (as suggested everywhere I could search), using cordova-plugin-wkwebview-engine.

However, I couldn’t make it work due to a blocking problem with a cookie-based authentication to a REST API server: cookies were not stored by the app anymore.

Furthermore, it seems that until cordova-ios 6.0 is released, some references to UIWebView will still remain in cordova-ios, which could lead to app rejection by Apple.
By reading cordova-ios discussions, it’s not even clear if cordova-ios 6.0 will be released before Apple decides to reject submissions referencing UIWebView, since no estimated date is available for both events.

OTOH, Capacitor seems a very interesting option: this blog article from Ionic states:

On September 4th, 2019, the Ionic team shipped a new Capacitor release […] that removed references to UIWebView.

BTW it seems to bring many nice improvements compared to Cordova’s approach.

However, the problem with failing cookie-based auth still remains.

It looks like that I have to adapt the app & its REST API to use a “non-cookie-based” authentication, like JWT.

Is anyone struggling with the same issues?

Is this path (using Capacitor + JWT) a good way to go?

Hello,

I don’t intend to start flame wars but helping picking the right tools.

The npm vs yarn fight looks more balanced than a few months ago.

For the biggest concerns, npm v5 introduced package-lock.json & its performance has significantly improved (even if yarn remains slightly on top).

Some folks are even going back from yarn to npm : see yarn vs npm 2018 and npm vs yarn 2019

Note that all the arguments are not up-to-date, for example there is YVM which helps overcoming the “different yarn versions across projects” problem.

While this competition looks good to get better quality package managers in the long run, IMO for Quasar that brings some unnecessary mess :

• Inconsistencies in docs : Quasar v1.0 installation shows npm instructions only, whereas best practices in upgrade guide recommends yarn => why not recommending it on install page too?
  yarn seems to solve problems when developing on windows => maybe show that warning on install page too, when detecting a windows machine (user agent…)?

• More problems : npm and yarn come with their own sets of problems, which I guess are piling up in support channels (forum, Discord…). However, choosing “strictly” one over the other would certainly hurt developers. npm is still “de facto” standard, and yarn got a lot of adoption when it had clear advantages over npm and all those devs won’t like to change back, even if the differences look now much closer.

For the moment, I would suggest the following to improve Quasar doc:

• On installation page, I would state clearly that either npm & yarn can be used with Quasar. As well, if the Quasar core developers favor one over the other, it should be stated and explained (if possible, with detailed & up-to-date arguments)

• On each command line involving the package manager, I would add some tab or button allowing to switch between npm and yarn instructions & keep the latest choice as a preference (maybe in a cookie) to be consistent across pages, when coming back to doc, etc.
  Therefore, the doc would “support” the two mostly used package managers, follow the developer preference, and remain concise.

Such a flexible display could even support future & not yet popular package managers, like the very promising pnpm.

I’ve created an issue here: https://github.com/quasarframework/quasar-cli/issues/194

Hello,
Same problem as @Sweetyy here.

Quasar CLI seems complaining about “ghost” lines of code concerning “Add to homescreen for Android…” which are not in my index.template.html file

Trying to narrow down the problem, the message occurs when in add this line in <head> section
<link rel="manifest" href="<%= htmlWebpackPlugin.files.publicPath %>statics/manifest.json"> (I’m migrating a project from quasar 0.14)

However, adding a line such as this one does not triggers the message :
<link rel="icon" type="image/png" sizes="16x16" href="<%= htmlWebpackPlugin.files.publicPath %>statics/icons/app-logo/favicon-16x16.png">

The “manifest” line looks useless in 0.16, as now manifest.json contents have to be declared in quasar.conf.js
https://quasar-framework.org/guide/pwa-configuring-pwa.html

=> I removed all “offending” lines in my index.template.html, however the error message is rather confusing :-s

The value you store in your component property multiSelect should be an array of the selectable values you want to be checked:

For example (following your data set):

this.multiSelect = ['x-b', 'rt-builder', 'max']

Whereas for “simple” select fields (single choice)

<q-select ... v-model="selectedValue" :options="options" />

you simply do

this.selectedValue = 'identifier'

Answered here too:
https://stackoverflow.com/questions/47035330/editing-the-selected-option-in-the-select-dropdownq-select-of-quasar-framewor/48227687#48227687