window object can't be accessed when using Angular Universal

[snrostov]

With angular universal/angular 4, app may be running in node enviroment. So, it requires server side implementation of log (got rid of 'window' object usage, etc):

EXCEPTION: Uncaught (in promise): ReferenceError: window is not defined ReferenceError: window is not defined at Logger.global (/Users/sergey/syst/msmev/redesign/angular/pgu/dist/server/index.js:43:24345) at new Logger (/Users/sergey/syst/msmev/redesign/angular/pgu/dist/server/index.js:43:24941) at MainModuleInjector.get [as _Logger_29] (/Users/sergey/syst/msmev/redesign/angular/pgu/dist/server/index.js:44:27364)

[langley-agm]

@snrostov Right, right now its going to have a lot of issues with that because it wasn't designed for server side logging, it wouldn't be intuitive for the end user to simply not see their messages in the browser console because they've been logged somewhere else. I did a bit of research but I haven't found some kind of abstraction for the browser's console, also there's a problem where we can't access the storage which is one of the main functionalities, I don't want to break that functionality in order to half support universal.

Imho its an oversight on their side, I'd expect server rendering not to affect how it usually works when not doing server side rendering, the idea and I believe they do keep browser's state sync'd with the back end, but I guess not for everything.

Any ideas are welcome.

You can see some discussion about this in #146

I believe the storage issue can be solved by using cache instead but most likely that won't solve the issue of messages not showing in the browser.

[wingsuitist]

@langley-agm often you want to track behaviour/logging on production system with clients (like real users that don't check the console.log()) and then you want to get those logs to a central server where you can debug and identify messages from production. (Maybe some strange timeout because someone with an old android version xyz is using GPRS internet connection or whatever... And you have to know and debug as well as report and monitor those logs for management and improvement...)

[wingsuitist]

The console.log part should be abstracted into a function which calls another LogBacken service that I can reject/replace. The default one would be the console.log Backend service, and then I can use other LogBackend services like some syslog or REST api or other online log-service cloud bla... I'm currently thinking about how I could implementat that. How would you inject the LogBackend into the LogFrontend service?

[langley-agm]

Hi @wingsuitist,

I understand what you are saying but the logger is not responsible for getting logs from one place to another, its purpose is to log the messages wherever you configure it to. I do hope to create an appender that submits the messages to a rest endpoint to get the functionality that you are talking about but that's something I haven't seen any logger do so far.

However I believe @snrostov's concern is not that he wants to see the messages in the server, its just that the module is not working correctly when Angular runs in the server using AoT since it accesses the "window" object, but Angular will only run some part of the code in the server not all of it, so some messages will end up appearing in the client and some others in the server, this is a separate issue that what you are referring to as you will still be getting some logs in the client only.

One more thing the client might not check the console.log, but you can access their server with your browser and check it yourself.

The main scenario this logger was built for was to log stuff in development and turn them off in production, however, a very common scenario is that you need a way to turn it back on in production through the browser and the way to do this is by exposing the logger config to the window so people can configure it using the browser's console.

[langley-agm]

@wingsuitist I believe #137 is related to what you are talking about.