Open lostintangent opened 8 years ago
I'll go back over my notes from the original spec, and 1) make sure we're implemented properly and 2) make sure that these types of questions are either addressed in the product (where applicable) or documentation.
@nikmd23 and I had a discussion on this and our tentative solution on this is to provide ability for users to hover for more explanation of what these tags mean. I do think that this is a really good way to provide context for users about those tags. I'll provide a mock for this soon!
@chetsangnil Sounds good!
I've done a mapping exercise to understand all the various log levels associated with the top Node and .NET logging libraries.
I'll pull together the report (it's in Excel) and send it out to the team.
The listing of levels and their groups are here: https://github.com/Glimpse/Messages/issues/4#issuecomment-187372256
This issue is closely related with #123 , [Logging - 3] Logging "Source", here's the pdf addressing this issue: Logging -3_V2 .pdf
Please refer content within the filter drop down from Nik's logs mapping excel spreadsheet here: LogLevels.xlsx
Iterated version for this issue. Logging -3_V3-2.pdf
There's a (technically hijacked) issue that covered this work from the dev side at https://github.com/Glimpse/Glimpse.Client/issues/123
The logs feature works great for me, but there are a few things about the UI filters that I'm unclear about:
console.*
method or something else? I wasn't able to figure out how to get it to do anything.Debug
relevant? I know that the browser has aconsole.debug
, but I had thought this wasn't available in Node? When I tried doing aconsole.debug
, it doesn't seem to work. Is this there specifically for client-side logs? Would it make sense to hide this filter if there aren't any client-side logs? Maybe it doesn't matter, but I just wonder whether a Node dev would find this odd. Additionally, even in the browser, I believe thatconsole.debug
may be an alias forconsole.log
, and I'm not sure how commonly used it is, so I'm curious if there's that much value it provides in general.console.log
, which I think is the standard logging mechanism, and I'm not sure whether it would be considered a "verbose mode" or not. If anything,console.debug
would seem more akin to what is traditionally thought of as "verbose data", but as #2 mentioned, this isn't even available in Node. Chrome calls this "Logs" and F12 calls this "Messages", both of which I feel like are better than "Verbose". This is obviously hugely nit-picky, so take it with a grain of salt :)console.assert
calls are labeled as "Errors", which is probably fine, but kind of strange, since as mentioned above, there are already filters for methods which are simply aliases (e.g.console.debug
), as well as potentially unused for Node (e.g. "Critical"), so not having a dedicated filter for a first-class type of console message seems somewhat inconsistent, but not really a big deal.console.time
/console.timeEnd
pairs show up as "Verbose"? Maybe the verbose category is the catch-all? If so, then I suppose my comment #3 can be disregarded, but it would be cool to have some kind of tooltip/indication as to what "Verbose" represents.In general, it would be awesome if the filter buttons had tooltips or something which articulated what they actually mapped to from a code-perspective, that way I could rationalize the functionality quickly.