Hacker News new | ask | show | jobs
by WendyTheWillow 903 days ago
The smell here is in the library, is the commenter's point. The solution would be to search for a better written library.
2 comments

Another issue is the opposite situation, where the library reads from the object multiple times, expecting the value to be stable, but the caller might change the value in between, either from the properties using getters or from the library being async. The library has to make a full deep copy to ensure that it's completely stable regardless of the caller's actions. Just freezing the input object would be confusing to the caller and still vulnerable to property getters.
That’s even worse! I would try to avoid a library with a function that fragile.
Sure! Use a library that deep-clones the object first, leaving the original parameter unchanged! And now it's slower than the original library you're criticising.
Or use a library that doesn’t modify the input…
By deep-copying it, right? Sometimes it is needed.
If you know what modifications you need to make (hopefully the library author does), you only need to clone the relevant parts of the object (e.g. with spreading). Deep cloning still isn't usually necessary unless you're doing wierd stuff.
The Date object would like to have a chat with you ;)
I know you were mostly joking, but for cloning dates you can "just" use the constructor (https://stackoverflow.com/a/69601256).
…the whole thread you’re replying to is about it not actually being necessary. To participate in this conversation you either accept that premise or disagree with it, passing it as a given is not really an option for the argument.