`flex-direction: row; box-sizing: border-box; display: flex;` added automatically

[mattiLeBlanc]

I am seeing flex-direction: row; box-sizing: border-box; display: flex;added on my component that is rendered in the router-outlet.

My app.component.html looks like

<pro-header *ngIf="!headless"></pro-header>
<router-outlet></router-outlet>
<pro-footer *ngIf="!headless"></pro-footer>

The router-outlet will render a component which I give a class fxFlex
via

@HostBinding( 'class.fxFlex') true;

so it is flexed.
However, when the components root DIV uses fxLayout column WITH an fxFlex, like

<div fxLayout="column" fxLayoutAlign="center center" fxFlex>

it automatically adds flex-direction row to its parent.
The rendered html will be like

<pro-header *ngIf="!headless"></pro-header>
<router-outlet></router-outlet>
<pro-securing style="flex-direction: row; box-sizing: border-box; display: flex;">
....
</pro-securing>
<pro-footer *ngIf="!headless"></pro-footer>

This row layout on the pro-securing component creates the side effect that when the footer becomes large, it pushes the pro-securing into the header. It doesn't allow a scrollbar.

I find this a bit strange behaviour.
I am looking for a header, content (can expand) and sticky footer. Scroll bar should automatically engage when content is larger then header+content+footer.

Any thoughts?

[CaerusKaru]

This is intended behavior, here's the rationale. fxLayout is a directive that indicates the presence of a flexbox container with certain direction. fxFlex indicates an element that can flex within that container. So when you say that you have an element with fxFlex and fxLayout defined, it means that that element is a container with a certain direction, and also should flex within its parent. Now here's the catch: if the parent doesn't have orientation defined already, ie it's missing its fxLayout definition, FlexLayout will add a default layout of flex-direction: row. You can of course override this by adding `fxLayout="column" instead.

[mattiLeBlanc]

@CaerusKaru
Thanks for answering.
I can't overwrite the parent since that is a component that is loaded by the router.
I can't add a fxLayout via hostbinding to the component annotation, since it is not compiled by angular.
If I wrap my component with a div, then I think that Div has the same problem that it is not stretching the body.

I am just experiencing a little bit of a different behaviour setting up my sticky footer with the new flex layout and Angular 4 compared to Angular 1.6 and the flexlayout version from Material Design.

[CaerusKaru]

Can you try wrapping the router-outlet with a div, and setting the flex on that?

[rosslavery]

This is the same as #263, and it was resolved in #365 .

The fix is to use the stylesheet of the routed component to set the correct flex layout you desire (row / column).

This way you do not need to depend on adding the fxLayout attribute to a non-existent dom element, or using HostBinding etc.

[ThomasBurleson]

So perhaps fxFlex should NOT presume that the parent layouts need flexbox stylings.

If we disable this feature by default, we could provide a FlexLayoutModule configuration option that allows developers to override default behavior:

FlexLayoutModule.forRoot({
  fxFlex : {
    forceParentFlex : true
  }
});

Thoughts ?

[CaerusKaru]

Love the added configuration, but could we wrap the config in a token instead? Same with breakpoints (but that could be a separate issue)

[mattiLeBlanc]

@ThomasBurleson I think turning it into a feature would be great. It allows more control by the library consumers, since everyone uses a different context/approach.

[sstorie]

Just wanted to add another voice to those experiencing this issue. I was trying to get my child component for the router to flex in the column direction and just couldn't. I posted this issue on SO:

https://stackoverflow.com/q/48451609/571237

...and created this minimal example on Stackblitz showing the issue:

https://so-48451609-routing-flex-issue.stackblitz.io/a

I understand the rationale, but this seems like a flawed assumption when considering the router-outlet tag used by Angular. I am happy there's a simple work-around using !important, but hopefully this can be cleared up.

btw, love the library and really appreciate the work you all do! I'm glad to have found something to move past this one quirk

[mcblum]

I'm with @sstorie on this one -- it seems like that's an assumption that should be off by default with the option to enable if the dev so desired.