Add possibility to customize Vuetify SASS variables and correctly define default font family

[sronveaux]

This PR was created following discussions in #324 where we mentioned the fact that the Roboto font, even though listed as a dependency in Vuetify documentation, was not really used in Wegue and could be removed.

Since 2018, the default font was set to Avenir, Helvetica, Arial, sans-serif inside the wegue.css file, however, the default Roboto is still in use in some specific circumstances (in the overlay of Geocoder results for example).

The idea here was to define this default font properly, not using a CSS class, but by redefining the Vuetify SASS variable which is in use inside the framework. Now, Roboto is not included anymore inside the build nor is it fetched through CDN dynamically during execution.

By doing this however, this PR opens a world of possibilities as all Vuetify SASS variables listed in their documentation can now be overridden, giving the possibility to fully customize the look and feel of Wegue!
The whole documentation about this can be found here. The list of global overridable variables can be found here and all the specifics to components can be found at the bottom of the component API pages. For example, here's the link for the ones about the v-card.

I've put this PR in draft for now as it's missing the proper documentation. I was wondering what you think should be written for this. A general explanation that you can override Vuetify SASS variables should be present for sure but would you also like to see an example of how to redefine the default font and the way to find the relevant information using fontsource.org as a reference? Or perhaps this could be postponed and added to the Workshop later...

Just tell me what you think about it and I'll amend and propose an updated version!

Cheers,
Sébastien

[chrismayer]

Thanks for this @sronveaux. I like the approach using the framework mechanism by variables instead of doing something around it.

I am also totally fine with getting rid of Roboto font, since it was not really used by purpose anymore.

Some background: I think Roboto was removed in a quick hack (and thus not fully fledged) because of upcoming DSGVO/GDPR regulation laws in Germany, I think this was around the year 2018.

So please go on, if you find the time 👍

[sronveaux]

Hello @chrismayer,

So, here's the updated version of the PR with some documentation added next to it.

Just to give some information about the design choices that were made:

• The SASS variables customization file was moved to app-starter/styles/vuetify-settings.scss. As a user should be able to override variables, this should not be in src as I did for fast prototyping.
• In the documentation, there is an example that shows how to redefine the default font to be used in Wegue. The user has to import the font inside the codebase somewhere as explained which is not as clean as I wanted first. I tried a first implementation where there was an empty file called app-starter/styles/fonts.scss in which a user could import the needed fonts by filling it like this:

@use '@fontsource-variable/space-grotesk/index.css';

And the vuetify-settings.scss looked like this:

$custom-font-family: 'Space Grotesk Variable', sans-serif;

@use './fonts.scss';
@use 'vuetify/settings' with (
  $body-font-family: $custom-font-family,
  $heading-font-family: $custom-font-family
);

This seems cleaner at first but then you come across the caveat explained inside Vuetify documentation where the imported font is added multiple times in the build, making it grow in size.
As stated there, we should only put variables, mixins, and functions in the settings file, styles should be placed in the main stylesheet or loaded another way.. That's why the documentation states you should import the font in WguAppTemplate in the end. Until now, the fonts were included in main.js which is the best place for that but it breaks the separation between custom code and core code if we continue to do it that way...

And to finish, there is another caveat mentioned on Vuetify site which is build performance: Vuetify loads precompiled CSS by default, enabling variable customization will switch to the base SASS files instead which must be recompiled with your project. This can be a performance hit if you’re using more than a few vuetify components, and also forces you to use the same SASS compiler version as us.
No problem for using the same compiler as they are, it was already included when migrating to Vite, but the first time you access the site in dev and the build time have increased a bit. It is not too problematic in my sense, if we compare it with the not-so-distant time of Webpack, but there's an impact. So please assess and see if it looks reasonnable to you...

If it looks good on your side, I'll remove the draft state and propose the PR officially.

[sronveaux]

Just amended the PR and rebased it on master to remove merge conflicts...

[fschmenger]

Hi @sronveaux,
this is a very nice addition! I tested a few options and it does what it is supposed to.

Could you add 1-2 sentences to migration notes, that a vuetify-settings.scss is now required (possibly just link the new documentation)?

I also wonder if we can somehow consolidate the documentation of theming in wegue-configuration.md with the newly available scss options. I just have to think of something clever, as one is an app-conf based option while the other is an additional styling file. Maybe just put a note under colorTheme and link the vuetify-sass-variables.md documentation from there? "For more advanced styling options see ... " Or maybe @chrismayer has a better idea?

I noticed we're making use of some hardcoded font-sizes across the projects css, e.g. in AppFooter, Map, AttributeTable. This wont go very well with customizable fonts. Maybe we should open up a follow up issue to keep track of some remaining tasks.

Oh, and I forgot one last thing: The documentation states that the sass pre-processor must be installed: npm install -D sass-loader sass. While sass is somehow installed under the hood I cannot see sass-loader in package-lock.json. Interestingly it still seems to work but maybe you should check..

Cheers Felix

[sronveaux]

Hi @fschmenger,

Thanks for testing this and for your review ! I'll amend the PR taking your remarks into account as soon as I have time...

I completely agree consolidating the documentation is something which has to be done somehow. If no other idea is given, I'll add a note "For more advanced styling options see ... " which was what I had in mind too...

Concerning, sass, your remark is completely legitimate but no worries, if you go down the same documentation page, they explain that for performance improvement, sass can be replaced by sass-embedded when using Vite, which is what they do in their official create vuetify template and which is what I did when upgrading to Vite.

Cheers,
Sébastien