Fallback for fxLayoutGap is missing

[silvioboehme]

Bug Report

<div fxLayout="row" class="sec1" fxLayoutGap.gt-sm="50px">

If you reload the page at SM breakpoint, the gap is set to 0px. Now increase the window to MD, the gap is set to 50px, which is fine. But now, if you decrease the window to MD breakpoint, the gap is still 50px, and in the console you will get this error:

Uncaught TypeError: Cannot read property 'endsWith' of undefined at LayoutGapStyleBuilder.push../node_modules/@angular/flex-layout/esm5/flex.es5.js.LayoutGapStyleBuilder.buildStyles (flex.es5.js:228) at DefaultLayoutGapDirective.push../node_modules/@angular/flex-layout/esm5/core.es5.js.BaseDirective2.addStyles (core.es5.js:494)

Maybe the fallback for fxLayoutGap is missing?

What is the expected behavior?

this works fine in version 7.0.0-beta19

What is the current behavior?

this is broken in version 7.0.0-beta23

What are the steps to reproduce?

https://stackblitz.com/edit/angular-flex-layout-seed-c3txci

[CaerusKaru]

This should be a really simple patch, and we'll try to get to it this week, but it might get bumped to next week. Regardless, this will be fixed in the next release.

[smile2014]

fxLayoutGap is set, fxFlex percentage does not take effect
https://stackblitz.com/edit/angular-flex-layout-seed-febhfn
@CaerusKaru

[CaerusKaru]

I'm not seeing the endsWith issue in the latest branch, it's probably been fixed by a previous commit. I am still seeing the lack of removal (see #1037), so I'm tracking that now.

[CaerusKaru]

Ok, here's the root cause analysis, and it's not pretty (for us, anyway). On each style generation cycle (init, breakpoint activation, etc), we run an analysis on all breakpoints and values to determine which should be activated, or more importantly deactivated. We do this by caching the most recently applied style values that either the style builder or style builder cache have returned. We then remove those styles when we need to.

In the case of layout-gap, however, the primary style generation actually happens as a side effect in the style builder. This is because there are no styles applied to the parent during generation, and thus caching would not apply those styles to the parent (e.g. we need to run the generation every time, no matter what). That's where the problem comes in. Because we don't cache those styles during primary style generation, we can't remove them later when there is no fallback.

We'll try to develop a solution to this, but thought it might be interesting to some to know what's really going on, and why this is taking so long.