Hi, i Have a Flexbox horizontally layedout with 3 Children, each child set with flex-grow: 1 but the vertical in the middle eats the whole space and pushes the third to the next row or doesnt let the last div grow to the size it should. Thought flex-grow: 1 makes all 3 three child gets the same width. Why is the vertical making trouble in this case (it has 100% witdth per default but should it not respect the third child)? Replaceing it with a Div works. Is there any best practice when to use a Div and when a VerticalLayout? Cant follow why it sometimes end in strange beheaviour.
And why does the Div has no .setFlexGrow() Method
HorizontalLayout horizontalLayout = new HorizontalLayout();
horizontalLayout.setWidthFull();
horizontalLayout.setWrap(true);
Div div = new Div("1");
div.getStyle().setBackground("green");
div.getStyle().setFlexGrow("1");
VerticalLayout div2 = new VerticalLayout(new Text("2"));
div2.getStyle().setBackground("blue");
div2.getStyle().setFlexGrow("1");
Div div3 = new Div("3");
div3.getStyle().setBackground("red");
div3.getStyle().setFlexGrow("1");
horizontalLayout.add(div, div2, div3);
add(horizontalLayout);
flex-grow: 1 makes all children grow by the same ratio to fill up the remaining space within the same row. Since VerticalLayout has a width of 100%, it will take up as much space as possible, which means there is no remaining space to distribute. And with wrapping enabled, the VerticalLayout gets wrapped into a second row as that gets it closer to a width of 100% (or in this case exactly to 100%). If you want to use flex-grow you’ll want to set the width of VerticalLayout to auto for example.
Now why does VerticalLayout use a width of 100% so that it does behave differently than a Div? Well, someone at some point thought that this would be a reasonable default, probably without considering that width: 100% is a bad default for children in Flexbox layouts because it makes flex-grow useless.
Thanks :) Thought i made something wrong. Then i will go with Div. Thanks a lot! (Would find i more sensfull when Horizontal and Vertical behave the same, so no 100% on their secondary axis)
Definitely agree that it would be better if VerticalLayout did not have that default width. We would remove it, but that could affect virtually every existing Vaadin (v10 or later) application out there, as it has been that way since 2018.
But regarding your particular case, note that you can use VerticalLayout just as well, you just need to remove that 100% width from it: div2.setWidthUndefined();
or div2.setWidth("auto");
i have another issue with that flex. but cant find the reason. Maybe i understand something wrong:
I have a Horizontallayout (which automatically has display:flex ?) and i set setWrap(true)
In this horizontal i have 3 Verticallayouts. Number 1 and 2 looks like:
VerticalLayout verticalCompleteDelivery = new VerticalLayout(); verticalCompleteDelivery.setSpacing(false); verticalCompleteDelivery.setWidth("auto"); verticalCompleteDelivery.setFlexGrow(1);
The third one should be all the way to the right:
But they do not use the full space. But shouldnt be both vertical layouts use free space to the right? Attached the green is horizontal and the verticals are red.
When i inspect the verticalLayouts, i cant see the flex-grow
Does anyone has an idea?
Ok, must i use horizontal.setFlexGrow(1, verticalLayout) in order to set flex-grow to the child? Then i see flex grow, but it still not pushes the 3rd to the end
Just a random note; if you wanna go full deep into flex layouting, I would recommend to use the FlexLayout instead of working your way into a higher lvl abstraction like Vertical and Horizontal Layout
It’s just a plan div with display:flex and Java API
Your example looks like something I would either build with Vaadin’s pro components like Board or Dashboard and if those aren’t available with a css grid (no java API available) or bootstrap grid (custom solution) approach
Yup. Create use case specific class and a meaningful API, that hides the complexity of the web/css/cssgrid. This way the UI code in your app is more meaningful and readable. The ```
BorderLayoutWithCssGrid in the linked blog article is an example of such, with disclaimers that I would probably build the API (and name the class) in a different manner if it wasn’t built as a “a replacement” for the similarly named Swing layout.
Nope (depending a bit how you define “responsive” and what you have inside), that is just an example how to implement BorderLayout like layout. If you would be my customer, my next question would be that how you want it to be responsive. That can be implemented in multiple ways and it then that should on my philosofy end up in the class name and API. Some things you can do/implement with css grid features or with e.g. by listening to some component size.
I have no idea what that improvement really contains (or will contain), but I know that it is well recognised that the current FormLayout don’t fit for all requirements. @rofa might have more details, if there are some already.
The main thing with the new FormLayout is that you won’t have to define ResponsiveSteps for form rows to wrap to multiple lines. Instead you define a width for the columns, and they wrap when they don’t fit on the same line.
No, I’m not sure why FormLayout was even brought up in this discussion, as I don’t see any mention of forms.
As for what you are trying to build, that sketch helps a lot, but would need a bit more detail:
Should something be scrollable?
You said it needs to be responsive, but how? How do you want that layout to render on a smaller screen?
What is the content in the blue boxes? Is it supposed to be aligned into a grid, so that e.g. the middle item in each box is horizontally aligned with each other?
But it sure is flexible.
that looks difficult. You mean never use directly with divs and css classes?