Advanced console.log Tips and Tricks (2020)
medium.com
medium.com
https://developers.google.com/web/updates/2015/05/quickly-mo...
Very useful when you are wiring events together on the front end.
Surprised there isn’t a standard way to do this in the DOM.
Don't worry, neither is the article. Words don't mean much I guess.
- `$0` to refer to last selected DOM node
- `copy(obj)` to copy something to clipboard (that might be hard to copy manually; for example long strings are often cut when selecting manually for copying)
> javascript:(function(){console.log("monitor event"); window.addEventListener('message', (e) => {console.log(e);});})();
that way I can click the bookmark and start monitoring events whenever I want
If you use arrow functions without a body you can log and fallback to the original statement.
Example starting point, you're wondering what message is. ``` const upperCase = (message) => message.upperCase() ```
Don't add a body, just log and continue:
``` const upperCase = (message) => console.log(message) || message.upperCase() ```
It is a bit subtle for my taste, though. My suggestion for clarity is to go ahead and make the function have a body with {}:
const upperCase = (message) => {
console.log(message);
return message.upperCase();
};
Of course you may disagree, but no argument there, as I said it's a matter of taste.(BTW backticks, either triple or single, do not work on HN. Indent by two spaces if you want code formatting.)
Any code that is shared shouldn't rely on that, I agree.
Thanks for the tip!
`const upperCase = (message) => (console.log(message), message.upperCase())`
The function body needs to be in parens. Maybe not the most useful for this case, but I've used this when setting logpoints in Chrome to log a variable and save it to a global for further inspection.
const result = array
.map(someFunction)
.filter(someOtherFunction)
.map(x => (console.log(x), x)) // debug here
.map(stillAnotherFunction);const foo = () => console.log && <Something />
That stops the body rendering, and you can use '||' if you want the body and the log.
console.log({x,y,z})
not
console.log(x,y,z)
Who needs pretty-printing, formatting libraries, string interpolation etc?
I wish there was a "debugger snapshot" functionality that does not pause execution and creates a snapshot of the current DOM and state.
Probably a performance nightmare but being able to continue and inspect what happened in retrospect is what makes console.log a powerful debugging tool IMO.
You could extrapolate this to the time-traveling debuggers we've seen for Redux and other tools. That stuff is super powerful.
It annoying.
I take advantage of this so that my .log lines are stuff I need while developing but they shouldn't get committed, that's what the actual named log lines are for.
If you can't or don't want to pollute your code with `console.log` for debugging (can't edit original code; too long to rebuild; etc.):
You can add "log points" (Chrome and Firefox at least) directly in source view of devtools at specific lines of code
https://www.thedevelobear.com/post/logpoints/
You can also use "conditional breakpoint" to do conditional logging with `console.log`, again, without leaving devtools.
If the objects to be printed change between console.log() and the actual printing, the output you see may not represent the state when console.log() was called.
let a = "hello";
console.log( a );
let a = "goodbye";
will always reliably print "hello", not "goodbye".What you're referring to is the fact that when you expand an object or array in the console, then you see the contents of that object or array at the time you expand it, not as it originally existed when console.log() was called.
This is why alessioalex's sibling comment is so useful. By logging the output from JSON.stringify(), you are logging a string whose value will not change.
This log is still synchronous, but when you expand it in the console its properties are dereferenced and may be different from when the original log was made. The log, however, is still instantaneous and synchronous.
If JavaScript devs don't know if a function is async or sync it just gives more evidence that JS is a monkey-language. LOL!
A function can call a third party service, or some subsystem running on the same computer, whatever. Regardless of the programming language, that service may or may not do stuff asynchronously after your call. There's no way to tell. I regard the console.log to be a third party service. Who the heck knows what it does, except it has access to your memory!
As for a third party service argument, you're just stretching the goal posts there to fit your argument.
I agree that the core language is not the worst problem with JS; that's what I was trying to say.
Regarding the other point about knowing whether something is async or not. Few languages will tell you if a function does side effects. They might spawn threads or processes, mutate the data you sent them, all after the call has returned. Languages where you can easily see that this will happen are few and far between, and they have strong static type systems.
It was because one message was console.info and another was console.error, which was going to stderr and so getting flushed differently.
A couple months ago I fell for it again.
const obj = {objection: 'overruled'}; console.log( 'console.log is the #%d %s API ever written %f\% no arguing! %o %O !!!', 1, 'greatest', 100, obj, obj);
I've tried to keep my example compliant but it's still a very tiny loosy-goosy standard, for example at least in Firefox you can write %.0f to skip printing the fractional part of the float, but the standard doesn't mention this.
This is solved by separating out your log library into a separate file, and then blackboxing it. Voila, original call points are preserved making debugging easier and your logs more useful.
const dog = { name: "Dog" }
console.log(dog) VM287:1 {name: "Dog"}
console.log({dog}) VM305:1 {dog: {…}}dog: {name: "Dog"}__proto__: Object
EDIT: perhaps a better description by someone else https://news.ycombinator.com/item?id=27524164
Also, please stop writing tech blogs on medium. That well paid tech people of all people would be constrained to a paywall-middleman is an indictment of our entire field.
DON'T YOU FEEL STUPID NOW?!