Feedback: Inconvenient mixin API. Consider adding a global access to the logger. about floggy HOT 5 CLOSED

Hmm. We are so accustomed to mixins that we never had this case.

@lukaknezic I think we should mark this as enhancement and tackle it when it's suitable schedule-wise.

@rodion-m If you need this now, you can implement it with some singleton:

// Create a loggy
mixin GlobalLoggy implements LoggyType {
  @override
  Loggy<GlobalLoggy> get loggy => Loggy<GlobalLoggy>('G');
}

// Implement singleton
class Log with GlobalLoggy {
  Log._internal();
  
  static final _instance = Log._internal();
  
  void _debug(String message) {
    loggy.debug(message);
  }
  
  static void debug(String message) {
    _instance._debug(message);
  }
  
}

And then call it like Log.debug('my message');.

from floggy.

@itsJoKr Thank you for a quick response! And thanks for a solution to use the logger globally. But I want to use a package that will be popular (and supportable), so I think at the moment lack of a global logger context can be a barrier for many users to use it. Let wait for other people opinion.

from floggy.

@itsJoKr I also wonder that comparing to mixin, wouldn't it be easier to make an extension on Object to get the current loggy?

extension LoggyX on Object {
  Loggy get logUI => Loggy<UiLoggy>('UI Loggy - ${runtimeType.toString()}');
  Loggy get logNetwork => Loggy<NetworkLoggy>('Network Loggy - ${runtimeType.toString()}');
}

from floggy.

Added global loggy in #34 (will be live with 2.0.1). Global loggy is automatically included and can be used as logDebug, logInfo, logWarning, logError. Due to limitations global loggy won't provide class name, but it can be disabled or filtered just like any other type of loggy.

from floggy.

@itsJoKr I agree we can look to add this as an enhancement in future versions. For now, the singleton you wrote should be sufficient.

from floggy.