Hacker News Reader

Comment by dylan604 | Hacker News Reader

Isn't that desired? You want to see what the object looks at at the time of logging. If you need to see it after some additional code has run, you log it again.

View on HN

The problem is that if you log one object multiple times, they all point to the same object.

So if between two logs it was modified, it reflects the new status on the log before as well.

I think you may have been confused and got how it is, vs how it ought to be the wrong way round.

to be honest, my experience with logging objects is so simple, i've never needed to try this live look into the object. my expectation was the log is a snap shot in time, not a live look at the object. an interactive view into the object does sound interesting rather than constant log entries for each step. which is how I would have tried to do something the first time only to be confused by it. TIL.

What the parent posts are trying to hint to you is that the default logging behaviour of the console is the live-look model, which is almost never what you wanted with logging. (Though it does have other uses.) To avoid the live-look, you can deep clone, or just stringify.

Wow, I never knew this.

That's just one of the reasons I always say...

https://twitter.com/justinvincent/status/1714866433426067573

You have it opposite… if you change the object after logging, it will retroactively change the logged version.

> You want to see what the object looks at at the time of logging

Yes. That's why you need to use structuredClone. If you don't, and you mutate the object, then you'll see the new values when you expand the object.

Reply on news.ycombinator.com