Poll: What LumoUtility classes do you use the most?

Flow
21

Would love to hear from you @maneesh2 also why you prefer Flex utility classes over HorizontalLayout and VerticalLayout, as well as whether you use Overflow classes for scrolling or for hiding overflow.

22

but… this is an international forum, how could I dare… :laughing:

23
  • In some use cases (nested hierarchy) Horizontal/Vertical layout seem too cumbersome especially when I do not require margin spacing etc
  • Overflow used either to specify scroll direction or hiding it
24

Thanks @maneesh2.

So re Div vs HL&VL it mainly boils down to the default whitespace on HL & VL being annoying?

Could you describe why you prefer Divs with overflow styles over the Scroller component?

25
  • I won’t call it annoying. It just saves me making explicitly calls
  • Compared to using one more Component in the nested hierarchy, using Div feels more ‘natural’
26

What if you could do var hl = new HorizontalLayout(false, false); to get a HL without spacing or padding?
Or if you could do var hl = new HorizontalLayout(Padding.SMALL, Spacing.MEDIUM) or some such?

Re scrolling, do you mean that you prefer the more low-level or lightweight Div over a component like Scroller?

27

  • new HorizontalLayout(Padding.SMALL, Spacing.MEDIUM) approach can work. Sounds more elegant than additional method calls.

  • I don’t know if I can explain this properly. The contents of Grid or ListBox scroll by default. For me, a Div with overflow is similar. The contents of the Div scrolls. That’s what I mean by feels more natural.
    With Div + Scroller, the Div scrolls (not only the contents) . These feels less intuitive to me, and I have added one additional component.

28

You can replace the Div with a Scroller. No need for both. Scroller is basically a Div with more features, like overflow indication (by default a line at the bottom or top of content is overflowing in that direction) and scroll-to-top/bottom calls.

You can recreate the overflow indicators with pure CSS nowadays in browsers that support scroll container queries (Chromium-only at the time of writing). With Scroller those work in all browsers.

29

I think what Maneesh means is that he still needs a Div inside the Scroller for layouting the contents.

The idea with Scroller is that it is specifically not a layout component, because combining scrolling with layouting can be a bit difficult to get to behave as desired, depending on the layout in question, so you place whatever layout you want inside the Scroller instead.

The drawback is an extra shadow root (which has very marginal performance impact these days), but you gain a scroll-to API, visual overflow indicators, and a rendering performance optimization (contain:paint)

1 Like
30

My approach for this kind of cases is a custom class. I give it a name and that already usually documents what it is and then it is easy to read why those values are chosen. E.g. new ThingRow() finally in the app code. There I find method calls in constructor very readable and maintainable.

To the original topic, I’m sidelining Rolf here and really wondering why those are so popular. I still haven’t figured out why utility classes would ever be better than using some Java API (HL/VL/FlexLayout with better feature discoverability, readablity, typing) or plain css (extending Div, hooked with classname, maybe with e.g. Lumo/Aura variables) than the utility classes which is essentially just a set of magic string to do some layout things🤷‍♂️ And I have wondered this in non-Vaadin contexts as well. Kind of multiple inheritance, yeah, but is it worth of downsides, I’m not yet convinced as the rules usually only adjust a single css property.

Kind of iterating my wondering here, if HL/VL are really heavy, why would utility classes be any better than making MyCustomLayout extends FlexLayout :thinking: FlexLayout has no shadow root or custom component, it is just a div with a typed Java API for flex box layout.

31

That’s what I’m doing in application where I don’t have a custom Grid-like system in place

1 Like
32

Some grid layout is definitely something that we should ship along in core Vaadin :+1: Probably today it should be based on css grid, something like there is in Viritin. Css grid is though so complex that maybe there shouuld be multiple classes because there is so many ways to use css grid and probably we should ship it with some higher level components with preset for common layout patterns.

33

Yeah, I mean, I’m kind of a CSS expert, and I struggle with css grid.
A single API for all the different ways you can hold that thing would be just as complex as the raw css grid API.

And then people say “oh but I just want to hold it this way!”

But others want to hold it other ways.

And those who have only used it the way LumoUtility supports are hardly even scraping the surface. There’s tons more potential in there that we should utilize.

1 Like
34

Just to be clear, I don’t mean CSS Grid :sweat_smile: I mean the good old bootstrap grid (but with container queries)

35

Ah. Column grid systems. Do you still use that approach?

(Also asking everybody else in this thread)

(Not criticizing. Just haven’t heard that name in a long time, and curious to hear how they’re doing…)

36

With css grid one can do those bootstrap like grid systems as well. One example from Viritin tests: flow-viritin/src/test/java/org/vaadin/firitin/layouts/gridsystems/BsMimicingWithCssGrid.java at v25 · viritin/flow-viritin · GitHub

37

Yes, everywhere - but not with media queries, container queries combined with a column-like grid is such a game changer for me. I can finally define (easily) response dialogs.

Of topic: the German government is forcing Kern UX on everybody where such a Grid (with media queries :smiling_face_with_tear:) is also included…

1 Like
38

Hi Rolf, to question 1:
(I referred to my Hilla usage in this thread before, so this will apply here too)
When designing the application and want to switch the direction of an layout, it feels easier to just change the class name instead of tag AND the class names.
Also div is shorter to write than vaadin-vertical-layout and vaadin-horizontal-layout and requires no import.

39

Question to those of you who prefer utility classes over the getStyle() API because the latter uses inline styles: What if it didn’t? What if the framework generated classnames and a stylesheet for those styles instead?

Let’s say you do something like

static final Style warningCardStyles = new Style()
  .setDisplay(Display.FLEX)
  .setFlexDirection(FlexDirection.COLUMN)
  .setBackground(Lumo.Color.WARNING_10PCT)
  .setPadding("10px");

warningCard.setStyle(warningCardStyles);

and the framework produced this

.x1a2b3cd {
  display: flex;
  flex-direction: column;
  background: var(--lumo-warning-10pct);
  padding: 10px;
}

and applied the x1a2b3cd classname on the element?

3 Likes
40

I would really love this!

Two wishes:

  • I would like to re-use those styles (like in your example: it’a static object); so that vaadin would only generate a classname once
  • I would like to optionally define the class name to make it easy to comply with external design systems / guidelines…

e.g.


static final Style CARD_STYLE = new Style()
  .setClassName("my-card")
  .setDisplay(Display.FLEX)
  .setFlexDirection(FlexDirection.COLUMN)
  .setBackground(Lumo.Color.WARNING_10PCT)
  .setPadding("10px");

// I can use my class name directly
card.addClassName("my-card");

// I can use the style object
card.setStyle(CARD_STYLE);
1 Like