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 will reflect on the entire scope and annotate the code with their runtime values, the same as you get when working inside a JetBrains IDE.
But it's JS, so you can tweak it without committing it to disk and so you get some form of REPL driven development. I can't remember the last time I've used a console.log over setting a breakpoint in the debugger and fucking with the application state at that point to understand an issue.
You can get quite close to that after you've bundled your code and deployed it to a server, so long as you've got good source maps going on.
Print debugging is invaluable, but I can't help but think there's something of Smalltalk or Lisp in how you can mess with your app within a sandbox through the inspector, at runtime. The only thing that breaks the model is the transpilation and minification, without sourcemaps.
Then you quit web development and start a new career.
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 object - it would have to walk every pointer in the object and replace the pointee with its own recursive full deep copy, making sure to detect and handle cycles well, and keeping track of every replacement to ensure referential integrity (e.g. if two random objects A and B both have a pointer to the same object C, the copied A' and B' better both point at the same C'). An unlucky console.log() could easily copy half of your heap into the console, and god help you if you logged a DOM element.
(Also, all these copies would not be garbage-collected until you cleared the console.)
An universal deep copy is impractical to implement (notice how nobody seems to ever implement it, at all, in any programming language), and having console.log() do one would be an incredibly powerful and unpredictable footgun. Meanwhile, if you want to log a static snapshot of an object, all you need to do is to write console.log(cloneForLog(object)), where cloneForLog() is a function you wrote that does whatever copying is appropriate in your situation.
I think the only bad thing about console.log() is that this behavior is not taught to people as a core and important aspect of the function. I guess maybe if console.log() was restricted to strings, and something like console.logPresentation() was a separate function for printing objects, people would check the docs first and wouldn't be surprised.
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 would have to do for a deep copy as you mentioned. The cost would be wasting cycles on this work even if nobody looks at its result.
But where it gets dangerous is if there's any side effects in following the object tree. If visiting for logging e.g. creates nodes, or changes them, or whatever. Arguably "you get what you ask for", but this and the performance hit for generating log output before anyone really looks at it deeply, are probably the main reason things are as they are.
In the current status quo, devtools requests values through CDP as you expand the nodes.
Based on experiences with using Expand recursively on surprisingly short JSON network responses, I get the impression either the CDP I/O or the JS driving it is quite slow. Or the implementation's just accidentally quadratic.
In any case, I get the impression the right solution would be to make V8 execute and retain the deep-copy internally, then forward bits of it over CDP as requested.
Hrm, now I'm curious if the underlying mechanics that power the HeapProfiler could be readily repurposed for this.
The only fundamental issue, which is likely been the central blocker all along, is representing objects that are cyclic; the implementation would be closer to "object snapshot" than "literal deep copy".
(CDP = chrome devtools protocol, ie what gets exposed over --remote-debugging-port.)
console.log({x, y});
const x = {value: 0};
console.log(x);
console.log({x});
x.value = 1;
Evaluate the expression:
const x = {value: 0};
console.log(x);
console.log({x});
x.value = 1;
{value: 0}
{x: {…}}
v {x: {…}}
> x: {value: 1}
x.value = 3
v {x: {…}}
> x:
value: 3
Moreover, if you expand arrow next to {value: 0}, you will see literally this:
v {value: 0} [i]
value: 3By this I mean, the x and y in the output will never themselves change value. They may be mutated, but they cannot be reassigned in the printed object. The printed object is exclusively referenced by the console itself, even if the nested objects within it may be referenced elsewhere.
> That could still happen with the contents of x or y themselves, but then it's no different from the original way (console.log(x, y);)
By this I mean exactly what you demonstrated, the point being that it had nothing to do with the original suggestion made by jchw.
To be fair, there is also an "i" in a square, reminding me about this behaviour.
Doesn't help on browser, though; the options arg to console.dir isn't part of the standard there.
Try this in a browser console: x={a:1,b:{c:1}};console.log(x);x.b.c=2;
then 'expand' the object, 'c' will be logged as 2, not 1
And anyway- JSON.parse(JSON.stringify(x)) would be preferable because you'd still get the browser's rich object exploration