Suggestion: Don't copy frozen objects

[ropez]

If part of the data being copied is a reference to an object that has been frozen with Object.freeze, it's not really necessary to copy it, as it can't be mutated on either side anyway.

My suggestion is to check Object.isFrozen, and only copy the reference if it returns true,

The point of this, is that it provides a way for the user to opt out of copying parts of the data. Not being able to do this is currently a problem for me, because there are types are not possible to copy using this function, and I don't have a way to disable it, since it's used inside another package (vee-validate)

[lukeed]

A deep clone cannot have any referential outputs, even if they're frozen. That defeats the whole purpose. While it may seem attractive at first, klona would be the only utility doing this & would cause weird edge cases. For starters, this would happen:

// foo = frozen object
input.foo === klona(input).foo; //=> true

.. .which would certainly surprise 99% of existing JS code bases' equality checks.

Also, blanket-checking every object to see if it's frozen is a significant performance loss. The only difference between these two klona/lite runs is the addition of Object.isFrozen(x) as the first Object-type case.

Current / Before

After

[ropez]

I accept your answer, and I don't intend to start an argument, but it's an interesting topic.

That defeats the whole purpose.

What exactly is the purpose of deep copying an object? In my experience, I can't think of a reason, other than preventing changes on one side from being seen on the other side.

The README states the following, which I interpret as basically the same as above:

The result is a structurally equivalent clone that operates independently of the original source and controls its own values.

This wouldn't be surprising to me, as it is the expected result if foo was some primitive value or a string:

// foo = frozen object
input.foo === klona(input).foo; //=> true

Since foo is frozen, the requirement that a change to input shouldn't affect the clone is still fulfilled, since I can't change the internal state of foo any more than I can change the meaning of a number.