Feature Request: Extending LogEvent's to use in LogFilter

[aytunch]

trafficstars

Having different severity Levels for looging is great but Filtering's main purpose should be filtering logs in terms of our in app features. In a big project It would be perfect to tag some Log objects with names like: "chatscreen", "pushnotification", "firestore", "storage", "hive", etc.

Then we would use the readily available LogFilter to decide which Logs we want to see + which severity level

class ChatLogEvent extends LogEvent {
  ChatLogEvent(
      Level level, dynamic message, dynamic error, StackTrace stackTrace)
      : super(level, message, error, stackTrace) {}
}

class MyFilter extends LogFilter {
  @override
  bool shouldLog(LogEvent event) {
    if (event is ChatLogEvent) {
      return false;
    }
    return true;
  }

logger.log("My Chat Log", event:ChatLogEvent); //I am not sure how the syntax would be here...

[haarts]

Ah. I think I know what you mean.

This is actually something I consider adding. In essence I want to name a logger. But I'm not sure that is on the correct level of abstraction for you.

What about you use a map instead of a string when logging?

Something like this: logger.log({message: "My Chat Log", kind: ChatLogEvent}) Then a filter could inspect these messages and decide whether or not to allow them. If you want to still get only the clean messages in the output, create a custom Output to do so.

[pitazzo]

+1 I would really love to see this feature implemented.

[haarts]

Please see https://github.com/leisim/logger/issues/68#issuecomment-786637080

I think it helps if you think about this in terms of different loggers for different (sub)systems. You basically flip it around. Not one logger with multiple types but multiple loggers with one type.

Does this help?