Re: Quasar build. Single inlined HTML file.

OK. Let’s see. Why would anyone want to pack an SPA into a single, huge html file; that’s terrible for caching and it’s exactly what most people don’t want. Still I’ve found that this could be really useful for hosting any kind of webapp in small microcontroller like the ESP32. I thought it would be a great idea to revamp my dashboard using the power of Vue. So in couple of hours I made a new UI for my MCU using Quasar and went straight to serve it … to good to be true.

There are two popular webservers for ESP in Arduino. The good old synchronous WebServer and a new, progressive AsyncWebServer. First, I tried using the AsyncWebserver (asynchrony is great right?). This implementation is very good at handling simultaneous requests, like those made by any modern browser, the problem lies in the small RAM memory available in the ESP32 (64Kb in my devboard). This webserver serves everithing from memory once memory runs out it chunks the response, a thing that happens with 700Kb quasar runtime “vendor.js” . Circunventing this seemed like a lot of trouble, so i when with plan B. The old synchronous server was still there.
Now i could serve huge files ( very slowly), but only one at a time. This causes an inconsistent behavior across web browsers. Firefox would load the content after a few retries, chrome based browsers, on the other hand, drop the request after the first connection reset, so the result would be the same, some files simply not downloading.
After a lot of headaches, I embarked on a quest to reduce the file size of all my chunks (No luck there).
So plan D let’s serve the entire site in one huge html file to avoid concurrency problems.

1- Disable lazy-loading:
Lazy loading is great for a regular web experience. Allows caching and delivers the UI in the less amount of time possible. Grows more useful as your webapp scales. In this case though, it is a problem since it means that every component that is loaded this way has it’s own js file, this means another request for poor ESP32 WebServer.

Documentation is very clear in that regard: https://quasar.dev/quasar-cli/lazy-loading

2- Inline JS and CSS into “index.html”
this is 90% of the website, so is 90% of the problem. For this I used HtmlWebpackPlugin.
Add to your dev dependencies.

"devDependencies": {
  ...
  "html-webpack-plugin": "4.0.0-beta.4",
  "html-webpack-inline-source-plugin": "1.0.0-beta.2",
}

HtmlWebpackPlugin: https://github.com/jantimon/html-webpack-plugin
HtmlWebPackInlineSource: https://github.com/DustinJackson/html-webpack-inline-source-plugin

I think this package is discontinued but I couldn’t find any viable alternatives. Normal release version won’t work with quasar, have to use the beta version.
In “quasar.conf.js” include the configuration:

extendWebpack(cfg) {
	…
	if (ctx.prod) {
		const HtmlWebpackPlugin = require('html-webpack-plugin');
          const HtmlWebpackInlineSourcePlugin = require('html-webpack-inline-source-plugin');
          cfg.plugins.push(
            new HtmlWebpackPlugin({
              inlineSource: '.(js|css)$',
              filename: './bundled/index.html',
              template: './src/index.bundle.template.html'
            }));
          cfg.plugins.push(
            new HtmlWebpackInlineSourcePlugin(HtmlWebpackPlugin)
          );
	}
}

Had to make some small changes in “index.template.html” so I decided to use a separate template without variables.

3 – Don’t use static assets.
The public folder gets copied as-is in build. Webpack doesn’t mess with it. Instead of using static assets use dinamyc assets (in “src/assets”).

Docs: https://quasar.dev/quasar-cli/handling-assets

The only thing we have left here are fonts. I’m still figuring that out, but so far this is pretty good compared to my old dashboard built on top of obsolete framesets.

@Ilia & @metalsadman thanks a lot didn’t know that about the scoped property

Helper classes are in “node_modules/quasar/dist/quasar.css”

Yes I read the docs, but declaring in conf.js is still an extra step since i have to declare both the css variable and the brand separated.

@ncamaa I don’t know the svg specification very well, right now it supports the style and transforms tag. I’ll implement separated style properties later. If you find it doesn’t work for a particular icon, let me have it so I can figure out where I got it wrong.

@zwiebel_s If you have that problem still, here is the codepen

I added the listener @update:pagination='goToTop'

That is the event that triggers on pagination change. I guess that’s what you wanted.

Is there any way of automatically adding css variables to brands. I’m trying to make a component and pass a custom gradient as a prop to component but the only way I got to do this was setting the brand manually in a boot file. Is there any way of adding new css variables defined in ‘quasar.variables.css’ automatically to brands to avoid this extra step?

@ncamaa after installing you pass as first argument to the executable the directory containing your svg icons. It will create inside that directory a js file containing an object with the string versions of the icons.

@ncamaa normal install is for running from package.json if you want to run it from command line install it globally.

@ncamaa I wrote a tool for that last weekend. svg-stringifier

I wrote a script to import all svg icons in a folder and then pass them to iconMapFn. But i can’t change the color of the images this way. I noticed that if use inline svg paths inside q-icon the color changes with quasar style classes. So I’d like to know if there is anyway of returning this svg paths in the iconMapFn so they behave like inline svg.

Re: Quasar build. Single inlined HTML file.

OK. Let’s see. Why would anyone want to pack an SPA into a single, huge html file; that’s terrible for caching and it’s exactly what most people don’t want. Still I’ve found that this could be really useful for hosting any kind of webapp in small microcontroller like the ESP32. I thought it would be a great idea to revamp my dashboard using the power of Vue. So in couple of hours I made a new UI for my MCU using Quasar and went straight to serve it … to good to be true.

There are two popular webservers for ESP in Arduino. The good old synchronous WebServer and a new, progressive AsyncWebServer. First, I tried using the AsyncWebserver (asynchrony is great right?). This implementation is very good at handling simultaneous requests, like those made by any modern browser, the problem lies in the small RAM memory available in the ESP32 (64Kb in my devboard). This webserver serves everithing from memory once memory runs out it chunks the response, a thing that happens with 700Kb quasar runtime “vendor.js” . Circunventing this seemed like a lot of trouble, so i when with plan B. The old synchronous server was still there.
Now i could serve huge files ( very slowly), but only one at a time. This causes an inconsistent behavior across web browsers. Firefox would load the content after a few retries, chrome based browsers, on the other hand, drop the request after the first connection reset, so the result would be the same, some files simply not downloading.
After a lot of headaches, I embarked on a quest to reduce the file size of all my chunks (No luck there).
So plan D let’s serve the entire site in one huge html file to avoid concurrency problems.

1- Disable lazy-loading:
Lazy loading is great for a regular web experience. Allows caching and delivers the UI in the less amount of time possible. Grows more useful as your webapp scales. In this case though, it is a problem since it means that every component that is loaded this way has it’s own js file, this means another request for poor ESP32 WebServer.

Documentation is very clear in that regard: https://quasar.dev/quasar-cli/lazy-loading

2- Inline JS and CSS into “index.html”
this is 90% of the website, so is 90% of the problem. For this I used HtmlWebpackPlugin.
Add to your dev dependencies.

"devDependencies": {
  ...
  "html-webpack-plugin": "4.0.0-beta.4",
  "html-webpack-inline-source-plugin": "1.0.0-beta.2",
}

HtmlWebpackPlugin: https://github.com/jantimon/html-webpack-plugin
HtmlWebPackInlineSource: https://github.com/DustinJackson/html-webpack-inline-source-plugin

I think this package is discontinued but I couldn’t find any viable alternatives. Normal release version won’t work with quasar, have to use the beta version.
In “quasar.conf.js” include the configuration:

extendWebpack(cfg) {
	…
	if (ctx.prod) {
		const HtmlWebpackPlugin = require('html-webpack-plugin');
          const HtmlWebpackInlineSourcePlugin = require('html-webpack-inline-source-plugin');
          cfg.plugins.push(
            new HtmlWebpackPlugin({
              inlineSource: '.(js|css)$',
              filename: './bundled/index.html',
              template: './src/index.bundle.template.html'
            }));
          cfg.plugins.push(
            new HtmlWebpackInlineSourcePlugin(HtmlWebpackPlugin)
          );
	}
}

Had to make some small changes in “index.template.html” so I decided to use a separate template without variables.

3 – Don’t use static assets.
The public folder gets copied as-is in build. Webpack doesn’t mess with it. Instead of using static assets use dinamyc assets (in “src/assets”).

Docs: https://quasar.dev/quasar-cli/handling-assets

The only thing we have left here are fonts. I’m still figuring that out, but so far this is pretty good compared to my old dashboard built on top of obsolete framesets.