NGXLogger support for non ng components / classes

[IsNull]

As the logger currently must be injected, it is cumbersome if you have a complex domain model in the web app consisting of plain and simple classes.

The way I know loggers from .NET / Java is that they can be used by static references. The question is if it makes sense to apply this pattern here to?

A middle ground probably could be a global, static holder:

class Foo {
    private static logger = NgxLoggerHolder.instance;
}

Optionally, depending on required information, we could also allow passing the current class, giving the opportunity to include the class name in the log.

class Foo {
    private static logger = NgxLoggerHolder.forClass(Foo);
}

The way I see it this system could co-exist with the current implementation and basically proxy to the configured instance once ready.

What are your thoughts on this?

[dbfannin]

I've been putting some thought into this for a while. Here are the big problems I would like to solve.

• This module is built for angular, but if I have non-angular classes in my project, I would like to use the same logger
• I would like to be able to have multiple instances of loggers and be able to create/get logger instances at my on discretion.
  • I would like to have some loggers report to a server side logging service, while others do not
  • I would like to prepend a unique logger id to each of my messages, so I have context of where the message is thrown
• I would like to only specify the config at the time of creating a logger instance, not on importing of the module
  • this becomes a hassle when you have a module based architecture where submodules may reference other modules referenced by your parent application.

So my thought is this doing something like this...

// manages the loggers
class NGXLogger {
  private loggers: {};

  constructor(public http?: HttpClient) {
    this.createLogger()
  }

  createLogger(loggerId: string = 'default', config: LoggerConfig) {
    const logger = this.getLogger(loggerId);

    if (logger) {
      return logger;
    }

    this.loggers[loggerId] = new Logger(this.http, config);

    return this.loggers[loggerId];
  }

  getLogger(loggerId: string = 'default') {
    return this.loggers[loggerId];
  }
}

// All of the logger functionality
class Logger {

  constructor(private http: HttpClient, private config: LoggerConfig) {
  }

  trace() {
  }

  debug() {
  }
}

[IsNull]

This module is built for angular, but if I have non-angular classes in my project, I would like to use the same logger

To achieve this, I think one approach would be:

common-typescript-library

• Define a clean API of the logger as interface
• Define a global, static logger builder where concrete implementations can register themselves
• Provide a simple implementation which logs against the console

ngx-logger

• Implement the logger interface and register it as NGX service for injection
• Implement an extended logger which supports server side logging

One important point is that a constructor is not part of the API, so it will be transparent to the consumers what is required by the logger and also where the logs will go.

I would like to only specify the config at the time of creating a logger instance, not on importing of the module

Well, usually you want to have the same config for the logger per project. The interesting part is that you want to config a logger implementation which you do not know in advance (i.e. . the generic logger builder API) - so i would go with a simple key/value approach.

A logger implementation will have access to all properties and will respect the ones he can.

However - maybe we should consider using an existing solution like this https://github.com/mreuvers/typescript-logging and provide additional features. Such as angular integration and server-side support.

[dbfannin]

@IsNull, sorry I'm just now getting back around to this. With the updates in 2.1.0, you can create a custom logger that is separate from the standard provided logger. I wonder if this gets us one step closer to your proposal.

We let the app manage creating the custom logger, and supplying it's own non-angular modules with that logger in whatever capacity the developer chooses. An improvement on that, would be to establish our own pattern, and support it by default, or update the readme with a section on how we suggest others do it.

Again, sorry I'm just now getting back to this thread. Thanks!

[IsNull]

I ended up creating a new logger library based solely on TypeScript, supporting global configuration and configuration of custom appenders and formatters: @elderbyte/ts-logger This was required as we already have lots of different TS libs and need a global log system.

If you are interested, we could merge our efforts and this ngx-logger could use the generic ts-logger under the hoods.

[dbfannin]

I've been giving this some thought. I think for now we'll keep our current logging functionality. If we get to a point that it feels right to separate, maybe we can chat then about consolidating our efforts. As of now, I don't see any benefits for NGX Logger adding TS Logger as a dependency.

I'll go ahead and close this issue for now, since the logger now supports a way to do this.

Thanks!