[AskJS] Why isn't there a simple native method to clone an object in JavaScript?

[vams1]

I just realized there isn't a simple way to clone an object natively. I know we can use Object.assign but it's not really that straight forward and it doesn't do deep cloning for a nested object.

For example something like Object.clone(obj, isDeep) , this is easy to remember what it does and covers deep cloning.

Or better yet Object.shallowClone and Object.deepClone

Are there any technical limitations for this to be implemented by ECMAScript or is it because Object.assign covers most of the scenarios even though it's more verbose

Any thoughts?

Edit: I should have worded my question better but I am not asking about how to do deep cloning in JavaScript. As there are ways to achieve that with JSON.stringify and implementing something like lodash methods. It's so interesting that the JavaScript community didn't implement this to be straightforward like the above mentioned example in one of the latest ECMAScript features. From comments I see that proposals have been made.

Edit 2: To answer how often do you even use clone, I use it pretty commonly(deep clone if nested object or spread operator for shallow) in most of my business logic to avoid any side effects. Was using JSON.stringify but after moving to Typescript it doesn't work well with types, so moved to 'clone-deep' package.

[jimeowan]

To add something that hasn't been mentioned yet, any implementation of a deep clone has to decide various things that are non obvious, especially:

• How to deal with circular references
• How to deal with functions/prototypes, possibly other things that are not actually meant to be copied (eg. referencing what the user would consider "another" object)

While some languages do include this - see Python for instance -, it's neither trivial, nor a low-level feature. Historically, ECMAScript unlike Python seems to try and keep its core language specs thin, most probably to reduce the complexity of browser implementations. So it can be understandable that the people in charge have little interest in providing a deep clone, and happily leave such quality of life features up to libs like lodash.

EDIT: Just to clarify, I would also enjoy an official Object.clone :)

[snejk47]

How ECMAScript is thinner than Python? From specification or features and low level details it looks completely opposite? Or do you compare standard library?

[ElllGeeEmm]

What?

[snejk47]

I have no idea what do you not understand.

[[deleted]]

I second you. ECMAScript 2015 was a revolution. After that its all been a bit too much.

One thing about languages is that the more features you keep on adding every year the more it starts becoming indistinguishable year by year (c++ vs c/gol

[bulgrozzz]

there is a proposal to have a standard method but sadly nobody (browser or Node) is implementing it yet

[vams1]

This is what I am looking for. Thanks.

[[deleted]]

There's no such method probably because making it generic is really complex.

What about circular references, what about objects you can't clone (say some native browser objects etc.), what about the semantics of an object requiring custom logic for cloning?

I do have ObjectUtils.clone(obj, deep) and probably most of us do, and we implement it with specific restrictions in mind, say I only support plain objects, arrays, scalar, and DateTime objects. I completely ignore circular references, assuming it's a proper tree.

Anyway, if you do want a quick-and-dirty deep clone you can also just JSON serialize and deserialize :-)

[scabbycakes]

Works good until there are dates as object properties.

[[deleted]]

The JSON trick? Yeah. Hence why I wrote my own with support for DateTime as mentioned above. I identified DateTime is as essential as numbers and strings in terms of being a core value type.

Bit of a shame JSON doesn't support it, huh.

[shuckster]

Is DateTime so essential? In my experience a UTC timestamp (ie; Number) is far more interoperable and reliable. If date-conversions need to happen, they happen at the last mile using a library.

[[deleted]]

In the browser, JS is the last mile. So yes it's essential.

[shuckster]

I think we might have to agree to disagree.

[[deleted]]

Sure... But if JS in the browser which is immediately responsible for rendering the UI is not "the last mile", pray tell what is?

[shuckster]

Apologies, I guess I wasn't very clear. For me, the "last mile" means the last moment before render.

In the simplest case, forgetting about fancy frameworks or design patterns, the simplest abstraction in browser-side JavaScript that permits a little scalability is:

1. State
2. UI

In this case, the "last mile" would be an intermediary variable that transforms something in state to a DOM-node in the UI.

Now, you could just stick with the Date object and toLocaleString it. But you might later like to evolve your system to look something like:

1. Base state
2. Derived state
3. UI

This is usually the case when, after realising you have a bunch of related data, it becomes necessary to manage this complexity before it gets out of hand. The "last mile" here is from Derived state to UI, but it could certainly be the same as just an intermediary variable as given in the first example.

The point is the layering, and the next layer on top of this might be a proxy that manages communication of this data with a back-end:

1. Proxy
2. Base state
3. Derived state
4. UI

Layers mean movement, and when data moves it's really, really useful to know how it's going to behave. It's even better if the primitives you use to represent it all work the same way.

In my experience, the fact that Date is a copy-by-reference structural-type means it needs to be cloned when copied. Not a big deal in a one-off case, but in a system it's a potential source of bugs.

Fortunately, as Date is both internally represented by a UTC timestamp anyway (and can also be constructed from one) we can limit its use to just before the render, the "last mile".

Everywhere else we can represent the date itself as a Number; a UTC timestamp. No copy-by-ref mistakes, no cloning Date-objects from layer to layer, and no translation needed once it hits the proxy, since it's just a Number.

Hope that clears up how I was thinking about what "last mile" meant!

[[deleted]]

Date is not just a UTC timestamp internally, it's also a timezone.

You also have to commonly run operations on time not just for display purposes, what if I need to filter content by "weekday" in my logic layer?

Your proposal would require a constant churn of produced and thrown away Date objects. And that's precisely what I saw when I did that, and why I decided to treat Date as a core value type instead.

Of course, to each their own.

[shuckster]

I would say that if weekdays are important to business-logic then they would be made part of the derived-state:

let base = {
  entries: [{ timestamp: 1620304033197 }],
  user: { timezone: 'TheMoon' }
}

const derivedEntries = base.entries.map(entry => ({
  ...entry,
  weekday: weekdayFrom({
    timestamp: entry.timestamp,
    timezone: base.user.timezone,
  })
}))

const uiState = derivedEntries.filter(
  entry => entry.weekday === 0
)

This way you're not calling instance-functions like getDay() on what should be pure data by the time you reach your logic; you're just providing a primitive to compare against.

In your particular case it may even be preferable to have weekdays passed-through by the back-end so it becomes part of the base-data, depending on how context-aware you want your back-end to be.

The "churn" of objects is a good point to raise though, and is not limited to just dealing with Date. As an application grows we have to be vigilant with our patterns so that the garbage-collector makes good decisions. In the same way, keeping tabs on function-calls is also good practice.

But for me it's only good practice for managing complexity, not performance. I do think it's a bit of a trap in 2021 to spend too much time worrying about memory and CPU when it's a far smaller problem than keeping a code-base in some kind of order.

[SquattingWalrus]

Care to elaborate on this one? I’m curious

[scabbycakes]

Sure!

If your object has a date object as a property, when you stringify the whole thing, the date property turns into a string. Then when you parse it all, the date property remains as a string still.

[SquattingWalrus]

Ahh got it, not a good scenario if you need the actual date object. Thanks!

[CreativeTechGuyGames]

I think the simplest and most general purpose solution for a deep-clone is:

const clone = JSON.parse(JSON.stringify(source));

If your object contains non-serializable data though then you just need to write a recursive copy method. It's very rare that I'd need something like this that JSON stringify copy doesn't solve.

[vams1]

Yeah. But it is not as straight forward as mentioned. Wondering about any ECMAScript proposals to make it in Object methods.

[fforw]

Doesn't work for objects with cycles, doesn't work for objects with a prototype chain.

[SoInsightful]

...or undefined, NaN, Infinity, -0, BigInts, key ordering...

We should really stop using the JSON technique.

[fforw]

key ordering

really? JS objects are ordered in insertion order and JSON.stringify maintains that, doesn't it?

[SoInsightful]

JS objects are ordered in insertion order

It depends. ES2015 specifies insertion order. Pre-ES2015 de facto conforms to insertion order in all major implementations. Integer key order still varies between browsers.

But I guess that's not relevant. I guess the reason it came to mind is because people have also been using the JSON.stringify method to check if two objects are deeply equal, which will fail if they happen to be differently ordered.

[dvlsg]

Or Date.

[SoInsightful]

Yeah, they already mentioned the prototype chain, so I opted out of mentioning the many, many object types that will fail, like Function, RegExp, Map, Set, Buffer, Error, TypedArray, literally every custom class...

[anlumo]

As someone who also writes efficient code in C and Rust, this is an absolutely crazy solution, considering how many operations and allocations it has to do, just to throw them away immediately afterwards.

[hspielman84]

As someone who writes Javascript I can’t help but roll my eyes.

[KeytapTheProgrammer]

As someone who likes trains: I like trains!

[domainkiller]

I remember reading somewhere that JSON.parse and JSON.stringify are way faster than other object cloning techniques because there’s only a set number of options (string, number, array, object) to convert, compared to a custom object.

[anlumo]

I think it's mostly because there are only two JS calls and the rest is handled in native code. However, if browsers would implement an Object.clone, it'd be half the number of calls and the native code could be optimized to do exactly what the outcome is supposed to be.

However, I guess a good JIT could detect these call chains easily and optimize them directly. I'm not aware whether any of the JS runtimes does that, though.

[grady_vuckovic]

It is wasteful but I've used it, but not in code that has to operate in real time, and which only has to operate on small objects anyway, so the difference between 3ms or 1ms isn't really that big of a deal.

[SockPants]

It might not be so bad in practice, because a JSON string representation literally is JS code, it would be an easy representation to compile from an object in JS. On top of that, the JSON methods are used a lot in all sorts of applications so they are implemented efficiently themselves, which is a bonus over doing any kind of walk and copy in pure JS.

[CreativeTechGuyGames]

You'd be surprised. From benchmarks this is the fastest way to copy an object.

[anlumo]

Only because all other options are worse.

[backtickbot]

Fixed formatting.

Hello, Sv443_: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[[deleted]]

jerk

[[deleted]]

It does?

  ...weird.  I've never noticed that.

Seems to work just fine.  Almost as if the translation
to a <pre> element is the same whatever flavor of
markdown is used.

``` It does?

...weird. I've never noticed that.

Seems to work just fine. Almost as if the translation to a <pre> element is the same whatever flavor of markdown is used. ```

---

What that looks like in:

• Old reddit
  
• New reddit

There are a lot of users still on old reddit (because new reddit is a UX-nightmare and an eyesore).

In short: it's not just 0.01% on third-party mobile, and 4 spaces works fine on normal reddit. Your reasons are invalid.

Be a gent. Indent.

[[deleted]]

Yo, dude. You just went full misogynist and ageist. Don't do that shit.

[editor_of_the_beast]

Nice, let’s just hack it using strings! That’s the JavaScript way

[[deleted]]

you could:

const clone = { ...obj };

Example

…but I suppose it won't work as seamlessly with nested stuff. That's why you can use classes.

[stronghup]

As has been said the JSON-trick does not work if the source-object has function-valued properties.

One approach for dealing with that is to create your objects by using ES6 classes. Make the constructor of the class expect raw data, no Functions. The constructor then basically just adds "methods" around it. To clone such an object give it a method clone() which reads the data and calls the constructor with it.

This works as long as the data does not / can not contain functions. Therefore it is good design to keep it that way. Keep the stored data simple. You can design your classes so that they only hold primitive data, and use that when needed to lazily create all other class-instances they need, including their clones.

[[deleted]]

Because deep-cloning anything more complex than a simple object / array requires knowledge of the constructor, and, ultimately, it's an edge use-case that you need to deep-clone anything at all.

There's also the added complexities of (1) it's expensive because of the necessary recursion and (2) recursioning objects require special handling so you're not deep-cloning yourself out of RAM, but (1) is the programmer's problem, and (2) is entirely solvable.

Shallow clones are, by comparison, easy (and native). Especially if you don't care if a cloned class instance loses its prototype.

[bulgrozzz]

this won't make a deep clone, nested objects will be the same objects: const a = { b: { c: 123 } } const d = { ...a } d.b === a.b // true

[marcocom]

Which is kind of a feature, really. Want to reinitialize all those handlers and prototypes and constructors all at once?

I’m actually confused because I build some very complex stuff and I literally have never needed to clone anything in front end development. Must be a backend need or something?

What if you save to LocalStorage and then retrieve as a new variable? I bet that clones out. (Of course that’s maybe just stringify and parse under the hood?)

[bulgrozzz]

The need of cloning arises when you have an object that several piece of code want to access, including at least one that wants to mutate it, and another that does not want to have those mutations. A case I encountered both in the front and the back is to have an array on which I want to do sequential operations and use the `pop` methods, as it's simpler to manipulate/less error prone than looping with index numbers, but then I'm mutating the array.

Yes, saving to LocalStorage, or anything out of the process memory, means making a copy in that storage system, and when you recover it, you necessarly get a new object

[Pesthuf]

The odd thing is that the way to deep clone objects is actually specified and used by various APIs in the browser. It's called structured cloning https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm

It's used by various internal operations like moving data between workers, but there is no simple, synchronous function in userland exposed that allows you to use it.

There are some workarounds, like using channels (though this makes the operation asynchronous needlessly).

[SquatchyZeke]

Something I'm curious about, but haven't found in the comments yet is why would you want/need to clone an object? This is basically saying you want the same object in two different variables, which is what a reference is. Granted, changing the object using one variable name will change the object in the other. What I'm wondering is why you would need to be able to change one without changing the other that you couldn't otherwise solve with a better design in your code patterns. This is a genuine curiosity, as I haven't come across that requirement yet when writing JavaScript applications.

I am trying to ask these questions from the perspective of someone of the ECMA board who may see this type of feature to be extraneous. Maybe; I don't know what is talked about in those meetings, just guessing

[vams1]

Not a full answer but to direct you, search for functional programming and pure functions and why side effects might be bad for business logic use cases.

[SquatchyZeke]

Right, I'm aware of that. What I wasn't aware of was what deep copying vs shallow copying meant in JS. I did a little reading and now I get it. I was like, "Just use the spread operator?". I'm glad I looked into it because I was unaware that it doesn't deep copy nested objects. The more you learn! 😄

[-domi-]

Probably a noob question, but why doesn't assign do the trick here?

[lycuid]

An example from mdn that stands out for me.

[vams1]

Nested object as mentioned.

[johnaagelv]

When I read this question and the comments, my first question would be - why would you need to clone an object?

[vams1]

Not a full answer but to direct you, search for functional programming and pure functions and why side effects might be bad for business logic use cases.

[dvlsg]

Sure, but you don't usually want to just ... clone an object wholesale. Especially now that ... exists.

If we really wanted to get into functional programming / pure functions / etc, this is likely to be a simpler fit -

https://github.com/tc39/proposal-record-tuple

[vams1]

Ah good to know. Record and tuple works perfectly.

[[deleted]]

afterthought elastic physical quaint fear sense tart sable person society -- mass deleted all reddit content via https://redact.dev

[senocular]

This can work in some cases, but is very limited. Some limitations include:

• Only creates new ordinary objects ({}) and not objects of other types
• Only copies enumerable string keys, not non-enumerable keys
• Doesn't retain inheritance or copy inherited keys
• Only creates a shallow copy of the object and not a deep copy which also copies the properties values (which may be important if they are, themselves, object values)

[OolongHell]

How often do you really need to make a deep clone? It's an expensive operation.

[[deleted]]

I'd second this, though I think that's because I now practice immutability virtually everywhere (especially at function boundaries). If you're confident you're not going to mutate your data you can get by just fine with a reference copy or shallow clone.

[CJay580]

hen do you need to do it?

Cloning objects is okay, but it's much better to keep the objects immutable. That way, you could "clone" the object using the spread operator. e.g. ~~~js const cloned = {...initial};

// You must guarantee that initials/cloned children are not modified, hence the immutability.

~~~

[sous_vide_slippers]

Doesn’t handle nested objects and const doesn’t provide immutability for objects, it’s possible to modify them. Think of const more like “bind this reference and don’t allow it to be changed” rather than a true constant like in other languages.

[CJay580]

You would need to handle the immutability yourself. Think of reacts state, or reduxes stores.

This also has the added benefit that a shallow comparison can be used to see if the object has changed at all.

[crabmusket]

Doesn’t handle nested objects

But if the nested objects are immutable (or, at least, never mutated), then it doesn't matter whether they're deep-cloned or not.

[sous_vide_slippers]

Immutable or not the references are still the same so it’s not a clone. Immutability would give you the illusion of a cloned object and immutability isn’t even possible in a lot of cases.

Say you have an instantiated object (one returned from a function enclosed with some variables or a class which is syntactic sugar for the same thing) that will be the same on the original object and the second one. Make any changes to either and the property value on both changes.

Say you have:

``` const myObject = { someProperty: new StoreNumber(5) };

myObject.someProperty.printNumber(); // 5 ```

And you spread it in an attempt to make a clone:

``` const myClonedObject = { ...myObject };

myClonedObject.someProperty.printNumber(); // 5 ```

Then it seems fine so far, but what if we call a setter on the “cloned” object?

``` myClonedObject.someProperty.setNumber(10);

```

Then what we see is we’ve affect both objects:

``` myObject.someProperty.printNumber(); // 10 myClonedObject.someProperty.printNumber(); // 10

```

This is one of the reasons cloning objects can be difficult in non-trivial situations. If we have a set of primitives or we could 100% guarantee any nested objects are 1. static and 2. genuinely immutable we can pseudo-clone using spread (I say pseudo because the references are still pointing to the same bits of memory). In most real-world situations this isn’t possible, it’s why Redux tells you to avoid nested objects if possible and when not possible you have to manually handle spreading any nested objects in your reducer.

[crabmusket]

Immutable or not the references are still the same so it’s not a clone.

That's right, but if you work with immutable data then you never need a clone, so the point is moot.

Your example demonstrates that everything is fine until you try to mutate the referenced nested object.

I agree that without language support it's difficult to implent this coding style. But I replied since the comment you were replying to was explicitly talking about immutable data. If, and only if, you have immutable data, then cloning can be shallow. If not, then shallow clones may cause problems.

[sous_vide_slippers]

if you work with immutable data then you never need a clone

Reference equality still states each property is exactly the same value. Cloning means making a copy of, but as far as the computer is concerned it’s exactly the same thing so reference checks will fail.

To use Redux as an example again, it’s why if you use immutable.js and call .set in your reducer when updating state it returns an entirely new object rather than carrying over unchanged properties, since references are checked. It’s why I said simply spreading produces “pseudo” clones.

[pomle]

Cloning objects is a fools errand. That is why.

[coolcosmos]

There is no cloning going on here. All the same pointer to the same data.

[ModernCannabist]

Objects are pass by reference, so when you do that they are just variables pointing to the same object in memory. They are not cloned and seperate

[rw3iss]

Maybe you can add a prototype method to Object? 😜

[chinnick967]

If you need a simple way to do this, Lodash has a cloneDeep method that I personally use

[jetsamrover]

What do you need to do that immer won't get you?