adamschwartz / chrome-inspector-detector

Detect if the Chrome Inspector is open or closed.
325 stars 17 forks source link

Group profiler probes and console logs #6

Closed thirtyseven closed 11 years ago

thirtyseven commented 11 years ago

The detector currently clears the console log every time it runs as a way of hiding the messages outputted by the profiler, this is not quite ideal when developing or debugging code. This set of commits hides the profiler messages in a collapsed log group, while preserving log messages from other running scripts.

It also reduces clutter in the Profiler pane by collecting the probe profiles under a profile group.

zackbloom commented 11 years ago

It took me a bit, so I'll explain what's going on. This creates a logging group to hide all of the profile logs. If you just create a group with each test, you end up with a whole bunch of closed groups littering the console. This, instead, preserves the group between requests, automatically ending it if anything tries to log to console.

What you end up with is: Screen Shot 2013-03-24 at 9 26 55 PM

All in all, pretty clever. It's the best solution to this problem, yet. Maybe @thirtyseven could include a comment explaining all of this for the future readers of the code?

adamschwartz commented 11 years ago

A huge improvement. Thanks!

(Slightly off topic...) I'm wondering if we should include a simple setInterval utility with the library (similar to the detect function in the demo code since that's most likely how anybody would use this. Perhaps that function could encapsulate this logic since the profiles are most annoying when running the test in a setInterval. Thoughts?

zackbloom commented 11 years ago

@adamschwartz And people could bind to events to listen for changes. I'd be happy to write it up, but I'm not sure how to handle the events without either A. bundling in jQuery or B. including an events implementation. In the meantime, callback: https://github.com/adamschwartz/chrome-inspector-detector/pull/7

thirtyseven commented 11 years ago

I've added an improved comment, any more improvements you'd like me to make? I was thinking of wrapping it in a function or class but I figured you guys have more stake in the design at this point so I held off.

zackbloom commented 11 years ago

I'm definitely on board with encapsulating it in a function. I actually think it should be entirely contained within the open.profile test, as it's only really applicable to that test.