flex-layout: Universal pre-rendered styles are not correct

I just published angular-css-flex-layout

Thanks @CaerusKaru, let me know if there is anything I can do to help!

@rkajbaf Unfortunately I have no idea what the real priority is. @ThomasBurleson is the main contributor and has a lot of other responsibilities in addition to maintaining this project. I remember reading somewhere that Flex Layout was going to be integrated with the Angular CDK at some point, so maybe they’re prioritizing that right now. Either way, this is an issue that I’m personally looking into, possibly blending parts of the ideas @alirezamirian suggested with some of my own, but I have no ETA for you.

@cyrilletuzi Can you open a separate issue for the vendor prefixes? (though as far as I know this is intentional – vendor prefixes should be preferred if available, no?)

As for the media-query issue, I see two possible solutions:

1. Implement the fx directives to use straight media-query injection only, and turn the media service into a no-op on the server (lest there be conflicting styles). This would mean the same (no-op) for ngClass.xx and ngStyle.xx (and *ngIf.xx when it gets here)
2. Have the Universal team implement a mediaQuery solution that involves picking viewport size from the user-agent (not ideal, but there is precedence for this behavior on the web)

The two options could be selected by user preference at bootstrap as follows: FlexLayoutModule.withServerMedia() or something similar (where default is to disable with SSR)

In my opinion, TB’s comment here is not viable, since (a) we don’t know if the user supports javascript at all, and (b) it’s a waste of network resources and loading time, which is what SSR, among other things, is trying to minimize.

@vikerman Do you see an alternative solution? For option 2, we could finally implement the WINDOW token (similar to DOCUMENT), and patch the window.mediaQuery function call on the server using a library like DeviceAtlas

Also cc @gdi2290 @MarkPieszak @alxhub @Toxicable Thoughts?

It’s very unlikely to change. If you want to come up with an independent solution, we would be happy to consider it.

Everything is still being finalized, but there will be a detailed writeup about everything closer to the release.

I created a css-only version of FlexLayoutModule with the same directives as @angular/flex-layout which adds required classes to work with AngularJS flex layout css. It’s a drop-in replacement for FlexLayoutModule of @angular/flex-layout with some limitations (ngClass., ngStyle., src.* are not available for example because they need js). For my own use case, it did a pretty good job and I’m going to put it on github in next few days. I hope it helps others as a temporary solution for SSR.

BTW, using this css based FlexLayoutModule doesn’t mean you can’t use other @angular/flex-layout modules like MediaQueriesModule (currently it’s the only other module).

These things are awesome and quite useful. However, a pure js approach has inherent issues with SSR, as the media size are not available in the backend and at best it can be estimated via client agent http header, which by the way, is not so reliable. because lots of platforms provide ability to change browser size, and if so, it’s impossible to know the actual media size in backend via client agent headers, and this will prevent smooth transition from server-side rendered content.

I think a css based approach can be used for directives (like AngularJS Material) while at the same time, other features like MediaQuery detection can be provided in pure JS, with the reasonable caveat of not being able to use them in server platform. By the way, the css based solution can be in form of scss mixins and functions which enables parameterizing breakpoints.

I’m thinking of creating a module that does the exact same thing that AngularJS Material layout directive does (which is basically adding required classes), with the exact same syntax of @angular/flex-layout directives and using that along with AngularJS Material layout css, as a kind of polyfill for server-side rendering. As the pure js approach of @angular/flex-layout adds inline style, it should be safe to use this module and @angular/flex-layout side-by-side.

Anything new on this thread? We’ve widely used this library and currently it’s the only big issue preventing our server-side rendering 😃

This is a known issue.

Issue:

Current SSR must handcraft the flexbox CSS for the initial rendered page.

Reason:

The flex-layout directives use the browser viewport size to determine the active breakpoint and generate the inline styles. Current SSR does not have access to remote viewport size.

@vikerman - We should discuss possbile solutions to this.