ngbracket / ngx-layout

Clone of the Angular FlexLayout
MIT License
184 stars 11 forks source link

fxFlex & fxLayoutGap rendering inconsistency fix proposal #43

Open Alexi996 opened 9 months ago

Alexi996 commented 9 months ago

Hello! I've been using FlexLayout for about 3 years now, and I love it. However, there have been some rendering inconsistencies which I want to propose solutions for:

1) fxLayoutGap: fxLayoutGap itself can cause several problems.

Problem 1: When used combined with fxLayout="row wrap", gap is not being rendered between element rows (See the image below. Row-wrap is rendered like described in example 1(red), and it's expected to be rendered like described in example 2(green)):

image

Problem 2) When used combined with fxLayout="row wrap", and the last rendered row has less elements than previous rows, the last row renders with an extra margin on the left, which makes the row look odd to the previous ones (in some scenarios, this extra-margin is appearing even when all the rendered rows have the same number of elements):

image

Solution proposal: -Both problems are occurring because fxLayoutGap is using MARGIN for rendering the gap. Solution is to use css gap property instead of margin. Additionally, directives for css properties like row-gap and column-gap can be added to be used in specific cases. (i've tested this solution in many scenarios already)

See the document: https://developer.mozilla.org/en-US/docs/Web/CSS/gap

2) fxFlex rendering inconsistently when using fxLayoutGap and different number of elements in rows: (Following example was created from a screenshot of one form from real-life project):

image

In Example 1, we can see that one additional fxLayoutGap in the bottom row is creating a rendering inconsistency. One workaround available within current fxLayout capabilities is to change the HTML nesting and layout, like it's done in Example 2, but a problem arises again if there is another row which needs to be consistent with the upper rows , and there are less elements (and less fxLayoutGaps). P.S. When we recreate the bottom row from Example 1 in the way that we put the first two form controls in one row which has fxFlex="66", and then nest this whole row together in another row with the third form control which has fxFlex="33", the problem still remains. Clearly, one additional fxLayoutGap is making a problem here.

Solution proposal: 1) 90% of those problems are fixed if css gap property is used instead of margins (i've tested this solution in many scenarios already). 2) SCSS calculation: For the most stubborn inconsistencies, I have created several SCSS mixins, and I think that some directives which would use them can be created (i've tested this solution in many scenarios already).:

//$width is a width of element, $gap is the gap used between elements, and $numberOfElemets is number of elements within a row or column;

@mixin calcWidth($width, $gap, $numberOfElements) { width: calc($width - (($gap * ($numberOfElements - 1)) / $numberOfElements)); }

@mixin calcHeight($height, $gap, $numberOfElements) { width: calc($height - (($gap * ($numberOfElements - 1)) / $numberOfElements)); }

//$part is a part of row/column which an element has to take (e.g. 3 for 1/3 of row), $gap is the gap used between elements, and $numberOfElemets is number of elements within a row or column;

@mixin calcWidthPart($part, $gap, $numberOfElements) { width: calc((100% / $part) - (($gap * ($numberOfElements - 1)) / $numberOfElements)); }

@mixin calcHeightPart($part, $gap, $numberOfElements) { height: calc((100% / $part) - (($gap * ($numberOfElements - 1)) / $numberOfElements)); }

If you need any info about my proposals, feel free to ask. Greetings!

DuncanFaulkner commented 9 months ago

Hi, not sure if this is the same or a similar issue, but a fix was put in for layoutgap check this PR https://github.com/ngbracket/ngx-layout/pull/29, it was released in 16.1.3. In the meantime, I will try and take a look at your issue, thanks for raising the issue.

Alexi996 commented 9 months ago

Hi @DuncanFaulkner , thanks for quick response. I just checked PR #29 issue and code, and it is not related to the issue I've posted. Okay, no rush, take your time. Thanks. :)