How to detect Lumo vs Aura in V25 🤔

Flow
1

Similar question in nature to recent Dark vs Light detection, I wonder how once could detect Lumo vs Aura in the upcoming V25 :thinking:

This is now topical as I’d like to at least prepare update of some add-ons and probably there are other add-on authors wondering this as well. There has bean some Lumo leakege into some of them and I wouldn’t like that we get lumo and aura variants of all the add-ons :grimacing:

A trivial example of the problem:

(Note: this particular case seems to work just fine :teddy_bear: as the LUMO_PRIMARY value is “primary” and Aura uses the same, but there are actual issues…)

Another thing that maybe somebody has solved, how to easily test add-ons with both themes :thinking:

1 Like
2

There is a section about upgrading add-ons in the V24->V25 upgrading guide (published just a few days ago) that covers that subject, amongst others: How to upgrade Vaadin applications. (TL;DR is that there is a ThemeDetectionMixin that can be used to load theme-specific styles.)

(Feedback and contributions to that guide are very welcome, obviously.)

3

No Java class called ThemeDetectionMixin, only on JS side?

4

There is a css selector to identify what is in use feat: add mixin for detecting Vaadin theme by sissbruecker ¡ Pull Request #10390 ¡ vaadin/web-components ¡ GitHub

5

You get that only if you use ThemeDetectionMixin, which is not applied to standard Vaadin components.

In general there is no solution to this problem yet. We’d need either or both:

  • A marker attribute on the document or host element of the Flow client to allow global CSS to target that
  • Some way to make that information available in Java code. Doing that automatically might be tricky since it requires waiting for the theme to load and then do a server call, only after which you could apply respective styles. Which is probably too late because at that point the add-on might have already rendered in the browser.

The only solution I can think of that works right now is for the add-on to provide theme-specific components / variants.

6

Oh interesting! Good to know :sweat_smile: I was kinda expecting to have to automatically applied to the root of a Vaadin app at 25

7

A solution to test with both base themes in an addon project (that uses Spring Boot for test UIs):

Not proud of it, but it seems to do its job :sunglasses:

8

I’m curious to know what the cases are when an add-on needs to know what theme the application is using.

Applying a theme variant is one, and the primary button example is kind of obvious. For that specific case, we’ve been pondering if that should actually be a core feature of the Button component, and not theme-dependent. That won’t resolve the whole topic, but just wanted to mention.

It might be suitable to apply both Lumo and Aura variants when you want to support both and use the built-in theme variants of a Vaadin component. Seems unlikely that there would be unwanted conflicts. For example, you could apply both the ButtonVariant.LUMO_ERROR and ButtonVariant.AURA_DANGER variants on the same button. But perhaps you want to apply “primary” when the app uses Lumo, but not when it uses Aura and instead use the “accent” variant?

For non-Vaadin-component parts of the add-on (i.e., custom CSS), add-ons should offer separate stylesheets for the app to import, one for Lumo and one for Aura.

9

That approach was not met with a warm welcome, because then an add-on is not just a drop in solution. Technically this is a new problem: there wasn’t any way to have automatic support for different themes from the Java side. For custom web components there was via the theme folder, which let Flow import the respective entry-point from the theme folder based on the @Theme annotation. So at least for that we created a replacement with the ThemeDetectionMixin that can automatically detect Aura and Lumo.

10

Please also remember that the actual case might also be neither Lumo nor Aura if the application has a custom theme built on top of the base styles. Or then it’s something that is technically based on either Lumo or Aura but customized beyond recognition.

1 Like
11

Using style properties is the most common I guess. Would need to conditionally drop in a different CSS for component with Aura or provide a fallback value (that probably doesn’t fit well into new them). Leaky, yes, what can one do :man_shrugging:

From Viritin, Badge is probably quite broken if Aura is used (haven’t tested at all yet):

Yeah and as a regular complaint, Vaadin provided Badge component would be great (like the Default/PrimaryButton) :teddy_bear:

12

Yeah, clearly. But this was the case which I believed would be solved by offering two separate stylesheets that the app chooses which to import. But as Sascha pointed out, this makes using an add-on more involved with an additional step as you need to remember to import the correct stylesheet. To me that feels natural, as it’s the application theme that decides how components should be styled. Explicitly importing the main stylesheet for Aura or Lumo is no different in that regard.

If I remember correctly, we used to have some “magic” for add-ons in Vaadin 7 and 8, that we auto-generated the “addons.css” file where all add-on stylesheets got imported. But you still needed to have the import for that “addons.css” in your main stylesheet explicitly.