add support for angular2-universal

[AnderssonPeter]

It seems this does not work with angular2-universal as it gives a error about the window object not exist.

Are there any plans to add support for it?

[MarkPieszak]

From looking at it at a glance, it looks like this library requires jQuery/hammerJS and has a few small references to window (all which don't exist on the server-side).

Unless these requirements were removed, I'd imagine this would be more in our ballpark on the Angular Universal side to at least (attempt) to support some of these features, which would slow down server rendering, or at least ignore them somehow (which means they just won't get rendered on the server-side). You can see the issue here (angular/universal#534), but it's nothing something I imagine we'll be able to implement soon as it's a huge overhaul. :(

[AnderssonPeter]

@MarkPieszak Ok thanks i guess ill have to look for a different CSS framework, do you know if there is a list with compatible css frameworks? (the only one i know is bootstrap).

[MarkPieszak]

ng2-bootstrap
https://github.com/valor-software/ng2-bootstrap

ng-bootstrap (think they have one issue with Carousel remaining to work perfectly with Universal)
https://github.com/ng-bootstrap/ng-bootstrap

Both work very well with Universal, they have no jQuery dependencies and have fixed any window/document references/etc.

Not sure why both teams didn't just combine their efforts :(
@AnderssonPeter

[rubyboy]

After moving to the Angular CLI this is now part of the library.

[bisubus]

@rubyboy How so? The library still relies on browser globals in entry point and custom-event-polyfill.

[rubyboy]

@bisubus is there anything we can do in the library to support angular universal? I thought we'd need support in MaterializeCSS itself.

[bisubus]

@rubyboy Definitely yes. I tried to go Universal before, and the ng2-materialize was one of the few show-stoppers.

The app will fail to bootstrap if MaterializeModule is included on server side, and it will fail if it's not (at least because materialize directive is used in templates).

Should we assume that materialize directive doesn't do any DOM changes that would be crucial to pre-render and it's safe to make the whole module a noop on server side by default?

[rubyboy]

@bisubus I'd actually assume that Materialize does do DOM changes. Worth checking in the original repo.
Do you have a suggestion how to add support for universal in the angular2-materialize library? Happy for a PR or work with you together on getting that implemented.
Thanks!

[bisubus]

@rubyboy Sure, we'll see how things go.

I've checked how it's going in Angular Material, and it looks like it still isn't ready for Universal, see angular/components#308, but there's supposed to be a separate entry point for server side, like angular2-materialize/server import. Makes sense.

The good thing is that in Materialize most visuals are implemented with CSS, while JS does interaction with user. Until JS part will be rewritten to native Angular DOM manipulation like @MarkPieszak suggested, I guess that stubbing materialize directive and ignoring window stuff for server side is the only reasonable way.

Another direction I see is that browser part (angular2-materialize import) has to be refactored a bit to make it more suitable for server side if a user wants to render it with jsdom or something (not even sure if jsdom can handle jQuery and Waves and other complex DOM stuff). Currently mocking global.window will result in incorrect framework behaviour, angular/angular#16545 . Since there's no built-in window service, I guess it makes sense to introduce something like MATERIALIZE_WINDOW provider that defaults to window global and can be easily substituted with jsdom. I guess in this case window.document from MATERIALIZE_WINDOW should be preferred over built-in DOCUMENT provider, too, since implementations will be different on server side.

What do you think?

[rubyboy]

I've reopened this issue, to keep it in the correct state. @bisubus as you said, we do need to put some effort in supporting universal.
Your suggestions make sense. I've never tried using universal, so it's hard for me to advocate on the correct approach. If we can keep the changes minimal, another option would be to have 2 entry points, to allow different imports (import 'angular2-materialize' vs. import 'angular2-materialize-universal', or something like that?). That would make the maintenance much easier, if the shared code inside the directly and accompanying classes is the same.

[susheelbanyal]

Hi there, It would be great help if anyone can tell me, how to remove the window is not defined issue in angular2-materialize with universal

[bisubus]

@susheelbanyal To my knowledge, it's currently better to not include angular2-materialize module on server side at all and stub its directives instead.