Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use console.log() like a pro (2020)

markodenic.com

Post reply on HN
Print view View original

141–150 of 156 posts

Re: Use console.log() like a pro (2020)

#141

Post by spondyl »

pjerem wrote: post #39
ollien wrote: post #27

Earlier quoted context omitted.

I much prefer it being collapsed. When dealing with large objects, the firehose can be annoying.

Then, one day, after 12 hours chasing a race condition bug, you learn that when you expand objects from console.log, it shows you the current value of properties and not the values at the time of the console log. Because the values are evaluated when you click on the arrow. Then you quit web development and start a new career.

Excuse me?! I just tried this out and I honestly never knew this until now. I can only imagine how much this has caused me trouble in the past.

Re: Use console.log() like a pro (2020)

#142

Post by greggman3 »

masklinn wrote: post #82
SahAssar wrote: post #49

Earlier quoted context omitted.

It's more that the way that the console reflects how the language works, and the console is not a log, it's a REPL (so console.output would have been a nicer name than console.log). I think it would be more confusing if the console did not work like the rest of the language does.

> It's more that the way that the console reflects how the language works, and the console is not a log, it's a REPL (so console.output would have been a nicer name than console.log). That is entirely irrelevant. The primary purpose of `console.log` is and has always be to generate output from normal, non-interactive programs. And it's completely wrong, `console.log` was absolutely intended as a logging method, as ev…

What I expect to happen when I do `console.log(obj)` is that it called `obj.toString()` which means I'd expect it to print `[object Object]` and that if I wanted to see all the values I'd have to either serialize the object `console.log(JSON.stringify(obj))` or manually generate a string `console.log(`field1: ${obj.field1}, field2: ${obj.field2}`);

The fact that the browser provides me this convenience of a link to an expandable live object is a bonus feature. I'm glad it doesn't try to deep copy the object. If it did it would make console.log useless because of the performance overhead.

If you want to capture all the fields then `console.log({...obj})` would work. But of course any of those fields that are references to objects will be live. I wouldn't expect any thing else. A print function shouldn't be required to figure out if your deep references are circular which would be required if you wanted deep copies.

Re: Use console.log() like a pro (2020)

#143

Post by quickthrower2 »

ljm wrote: post #123
jchw wrote: post #2

Another trick that might be more practical for actually debugging is using the object shorthand. For example, instead of... console.log(x, y); which contains the information you need, but lacks any useful context, try... console.log({x, y}); ...which will print out like an object, including the key names.

The best trick for actual debugging is to leverage your browser console. In a local build you basically have a 1:1 mapping of source code to deployed code and the debugger here basically becomes your IDE. You can hit Ctrl+Shift+P in the inspector and use the same kind of fuzzy file matcher you have in Sublime Text or VS Code, and from there you can set breakpoints, modify the code in memory, and so on. The console wi…

I bet the last time you used console.log was a race condition bug then :-)

Re: Use console.log() like a pro (2020)

#145

Post by pfundstein »

bluedino wrote: post #127
intellix wrote: post #125

99% of Frontend developers don't know about the debugger/developer tools. You can even log stuff without ever writing/compiling directly from Chrome Developer Tools

>> 99% of Frontend developers don't know about the debugger/developer tools. How is that possible?

I think what he meant is:

> Most frontend developers in my experience don't know about developer tools.

I still don't know how that's possible though.

Re: Use console.log() like a pro (2020)

#148

Post by comex »

ajcp wrote: post #62
nkrisc wrote: post #56

Earlier quoted context omitted.

I just see a tree and a name, is that all it is? Not sure what you meant but I’m on my phone so I can’t really look at the console.

Go to the desktop version and open the dev tools console :)

No output in Safari for some reason. I see it in Chrome.

Re: Use console.log() like a pro (2020)

#149

Post by anyfoo »

anyfoo wrote: post #136
TeMPOraL wrote: post #128

Earlier quoted context omitted.

FWIW, it's not like it could work in any other way. When you console.log() an object, it just stores a pointer to the object, and decorates it with an interactive label containing some text, so that it looks nice. This is fast to do, and most of the time, it's exactly what you want. To log a static snapshot with equivalent interactive expansion capability, console.log() would have to do a general deep copy of your ob…

> To log a static snapshot with equivalent interactive expansion capability, console.log() would have to do a general deep copy of your object Not necessarily, and if it did I don't think it would address the actual problem. console.log could do all the presentation work upfront, right then and there when you log, and provide a collapsed view of that. This would have to include detecting and cycling handles, as it wo…

Err, handling cycles, not cycling handles. Can't edit anymore, but funny anyway...

Re: Use console.log() like a pro (2020)

#150

Post by yepthatsreality »

ksenzee wrote: post #135
yepthatsreality wrote: post #114

> Using console.log() for JavaScript debugging is the most common practice among developers. But, there is more… Cut your debugging time, knowledge of console.log, and mental churn in half and set up your tooling to use a `debugger` statement. The console.log method may be used heavily but it’s actually a bad practice and often leaves code littered with log statements. Even for the purpose of logging itself you shoul…

Browser debuggers are amazing. I've been using them since Venkman. There's no substitute for setting a breakpoint, via the UI or a `debugger` statement, and watching your code execute a line at a time, in context. But that doesn't make console.log() a bad practice! The console is a great tool I am glad to have, especially when I remember the alternative, which was calling alert() and getting [object Object] and wanti…

Use console.log for it's intended use, formatting string output, but for debugging purposes, it is a bad practice because the reason it's used usually do not usually justify the sloppy unfocused mess it leaves behind. A poorly written log statement is tech debt, as well. Debugger provides all the benefits one would expect with console.log usage:

1. You can see where you are at that moment of execution in code

2. You can see variables and arguments within scope

3. You can forget about it and a linter will pick it up or it will be ignored unless run in debugging mode

All of this allows you to focus on the actual bug and not looking for something like:

`MY SPECIAL VAR: [object Object]`

I forgot to format, let's run it again.

Post reply on HN