You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When developing js applications and using console for logging one gets used to being able to provide an arbitrary number of arguments (with arbitrary types).
when using cat-log4angular this api changes sagnificantly.
first of all it only supports a single argument 'message'. when one tries to provide more then one argument it fails, except if the second argument is a function, as it changes the methods behaviour completely.
the second thing is that a string message is expected, as otherwise toString() is called implicitly (with the exception of Error instances, which aren't handled ideal either).
i would suggest changing both of these behaviours.
the actual log implementation should accept an arbitrary number of arguments and pass them along to the appender implementations.
for example the console appender could then look something like this
which would correctly utilize the console handling of logging arbitrary types
the problem arises with the 'timing' functionality - this cannot be changed without breaking the current api, but i think it is worth it and just provide a cleaner api for it
something along the lines of:
log.debug.time(function(){/* code to be executed and 'timed' should be able to return a promise or utilize a callback */});
The text was updated successfully, but these errors were encountered:
When developing js applications and using console for logging one gets used to being able to provide an arbitrary number of arguments (with arbitrary types).
when using cat-log4angular this api changes sagnificantly.
first of all it only supports a single argument 'message'. when one tries to provide more then one argument it fails, except if the second argument is a function, as it changes the methods behaviour completely.
the second thing is that a string message is expected, as otherwise toString() is called implicitly (with the exception of
Error
instances, which aren't handled ideal either).i would suggest changing both of these behaviours.
the actual log implementation should accept an arbitrary number of arguments and pass them along to the appender implementations.
for example the console appender could then look something like this
which would correctly utilize the console handling of logging arbitrary types
the problem arises with the 'timing' functionality - this cannot be changed without breaking the current api, but i think it is worth it and just provide a cleaner api for it
something along the lines of:
The text was updated successfully, but these errors were encountered: