Turns out there’s already a Quasar plugin for Local or Session storage that I had not noticed before: https://quasar.dev/quasar-plugins/web-storage

This would still be subject to the iOS problem of randomly deleting data when low on storage space, but nevertheless it’s a plus that it is already built into the framework.

@metalsadman Thank you, I wasn’t familiar with these packages either, they look useful and easy and would be great to stay within the Vue ecosystem. The problem here is relying on LocalStorage, which iOS seems to wipe out without warning when devices get low on disk space (see link in previous reply, or https://forum.ionicframework.com/t/ios-localstorage-persistence/20004/2). This doesn’t appear to be a problem on Android.

@digiproduct Thanks for this, I wasn’t familiar with dotenv but yes this is certainly useful. Unfortunately however it is not a full solution as you cannot edit values or write new ones at runtime. Turns out this is a real mess in Cordova. The plugin I referred to has a major issue about it simply not working on iOS 8+, and there’s been almost no activity in nearly a year – the project may be dead. Same with some other projects with native hooks into NSUserDefaults (iOS) and SharedPreferences (Android).

Then there are solutions which build upon LocalStorage, IndexedDB and/or WebSQL. Problem there is that iOS will simply delete this when a device is low on space (see the caveat halfway down the page here as an example: https://pouchdb.com/faq.html#data_limits). Doesn’t appear to be any workaround.

The only reliable solutions may be to go full SQLite or a custom config file. Remote or cloud may generally work too but not for this particular project. Still researching it. Thanks for the help.

Working on a corporate project targeting Windows and iPads. I need a way to store basic user preferences and settings (like a config.ini). Electron has a couple of packages that look like they will work (electron-store, electron-settings) and then Cordova has cordova-plugin-nativestorage.

Before rolling my own solution, does Quasar have plans for a persistence API? Are the above packages recommended for implementing persistence? Have I missed other options? Could this be implemented via an app extension?

Just noticed this behavior on a site I’ve upgraded from 0.17 to 1.0 beta. It’s a Q-Select with autocomplete filter. On mobile devices only, once the field is selected, it’s like a dialog (rest of the screen gets greyed out) and the select field moves to the top of the screen. Users can see the original select under the grey so it looks a little strange.

Is this “mobile mode” documented? I don’t see anything about it on the QSelect docs page.

It appears this cannot be overriden or disabled: https://github.com/quasarframework/quasar/issues/4007

Will that be an option in the future?

Are there any options or positioning that can be customized?

Sorry for the late response. Quasar is a great project and I certainly don’t mean to violate the wishes of the core project team. But, as far as I can tell, there is no supported way to use a font created with Fontello, and the project I’m working on needed some icons that weren’t part of the supported sets.

I did suggest a fix for future development (defining custom font prefixes in quasar.conf.js), but given that we are presently right between 0.17 and 1.0 beta I am not comfortable creating a PR because I don’t want to break backwards compatibility, nor do I want to introduce new features during a beta/RC phase. Or when the app-extension docs are available, I can look into that.

(I’m writing this while 1.0 is in beta, however, neither the current docs for 0.17+ nor 1.0+ appear to support custom font sets.)

Using Fontello, for example:

• Select the Fontello icons you want, then in Settings, use a unique CSS prefix (for example, abc-), then name and download your font package as a ZIP.
• Create a new folder inside /quasar/node_modules/quasar-extras for your custom font
• Inside the new folder, copy the base CSS file from the ZIP download
• Also inside the new folder, copy the font folder from the ZIP, including the folder contents
  • Note: Fontello’s CSS puts the CSS in its own subfolder, whereas we have put the CSS in the base folder, which is required by Quasar (because of css-loader module). This means we will need to slightly edit the CSS file so the path for the font files start with ./font instead of ../font Keep in mind if you add new icons and re-download the ZIP, you’ll have to re-edit the new CSS file
• In the quasar-extras folder, copy the ionicons.js file, rename it for your custom font, and edit the file so it points to your new CSS file
• In quasar.conf.js , add your font in the extras section
• Final step - however, this edit is likely to be overwritten any time you upgrade Quasar, so it will likely have to be repeated later. Check your custom fonts any time you upgrade. Edit the file /quasar/node_modules/quasar-framework/src/components/icon/QIcon.js. Line 18 (on 0.17+) includes the code || icon.startsWith('icon-'). Copy this and paste it right after itself, except change icon- to the custom prefix you set in Fontello. So now the line contains || icon.startsWith('icon-') || icon.startsWith('abc-')
  • Basically, you are telling Quasar not to mess with the class of the icon, not to assume it is part of a different icon set.

Now, you should be able to use <q-icon> tags or icon="" attributes inside Quasar components with your own font icons!

Because you have to edit the source code of QIcon.js, this is hacky and not stable. If I could make a request/recommendation, I would like to see the ability to define a list of icon prefixes which Quasar would know not to change (currently, an unrecognized or unprefixed icon name is assumed to be from the Material Icon set). Something like { custom: ['abc-' , 'myicons-' , 'app-'] } in the extras section of quasar.conf.js.

@israel965 I ran into the same problem. I finally got the fonts working in “build” distros by providing relative paths from quasar/.quasar

So instead of src url(/fonts/OpenSans.ttf)
try src url(../src/css/themes/fonts/OpenSans.ttf)
obviously, customize the path to your font files, but keep them relative, not absolute

I will note this is probably only a good idea for local apps such as electron or mobile apps. Webpack will rename font files, so that cached versions of the fonts cannot be used, which, for a web site, will slow down time to load the initial page significantly.