Live data from Hacker News

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

markodenic.com

81–90 of 156 posts

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

#81
This brings to light an issue I have encountered recently which has caused me to rely on console.log more than I would like.

In a recent project I have started using async/await, and seem to have lost the ability to use the debugger effectively. Breakpoints no longer seem to work properly. Its a huge negative, and im thinking of rewriting a lot of the code to remove async/await if I cant fix this issue.

Has anyone experienced this? If so, is there a way to fix it, or is this what I can expect when using async/await?

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

#82
post #26

Earlier quoted context omitted.

That's an anti-feature. When you log something in traditional sense you are recording something at that time.

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 evidenced by its siblings `debug`, `info`, `warn` and `error`, pretty much like every logging API out there.

It's also ahistorical revisionism "the console" was added very late into the history of the language, it and the entire console API were added by Firebug in the mid aughts. The language had been a thing for a decade at that point.

> I think it would be more confusing if the console did not work like the rest of the language does.

It would be the exact opposite. When I try to output something, my intent is to show the state of that thing at that point. That JS consoles are lazy (and even deferred) has systematically been a pain point and a pain in the ass leading to eager deep cloning to ensure I can see what I actually have on hand at that point, especially in mutation-heavy code.

I'm absolutely certain the number of times I've considered the behaviour a feature rather than an annoyance is 0.

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

#83

This brings to light an issue I have encountered recently which has caused me to rely on console.log more than I would like. In a recent project I have started using async/await, and seem to have lost the ability to use the debugger effectively. Breakpoints no longer seem to work properly. Its a huge negative, and im thinking of rewriting a lot of the code to remove async/await if I cant fix this issue. Has anyone ex…

I've experienced this when the async/await is not handled natively (for example when targeting ES5/6) and chrome or the sourcemap have it difficult to map the original code to the executed js.

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

#85

Another tip I found very useful lately You can use `$("selector")`, even without jQuery, in console. (not sure if with firefox, works with safari and chrome) And also `$x("path")` for xpath. But note, this works only in console, it’s not available from javascript.

You can also use $0 to get the currently selected element in the inspector.

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

#87

Didn't know about the string interpolation. Don't see a reason to use that over built in JS string interpolation (i.e. `var is ${var]`), but still interesting.

Somethings don’t log correctly if you use the built in interpolation without using JSON.stringify. And if you use stringify it’ll actually “freeze” it and it will not be interactive.

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

#88
post #9

I often always do this to deep print my javascript object. console.log(JSON.stringify(myObject, null, 4));

This is great trick because the console will keep a reference to your object, not a copy, so if it changes between the time it was logged and now then the log expando shows the new value, not the old value. By printing out the object you get a point-in-time snapshot rather than a reference to a mutable object.

Yup, learned it the hard way lol.

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

#89

Earlier quoted context omitted.

No, this is totally different. In the second version, if someObj changes after it was logged, when you'll expand it you'll see the updated value. JSON.stringify freezes the value. To get the same as the first example, but interactive, you have to do: console.log("some label: " + JSON.parse(JSON.stringify(someObj)))

> you have to do Technically you'd have to do console.log("some label: ", JSON.parse(JSON.stringify(someObj))) > In the second version, if someObj changes after it was logged, when you'll expand it you'll see the updated value Yes, this is something to be aware of (and is getting beaten to death throughout this comments section), but if like me you mostly use plain objects in an immutable way, you generally don't hav…

> Just keep this in the back of your head

I would never debug with that mindstate. I don't trust myself.

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

#90
I think the very fact that you have to rely on things like that when debugging speaks volumes about the language deficiencies. Or maybe it's just the tooling or environments where JS is executed?

In any case, the debugging experience is probably the biggest reason why I dislike modern web dev and tend to steer my career towards back-end.

Post reply on HN