Finally Fix Your Issues With JS/React Memory Management 😤

[@aaronalquiza9680]

Hi Jack, your no-bs typescript playlist was the last thing i watched before my interview in a company last year. a lot of your information stuck with me and helped me get into the company. i've been a senior software engineer there for almost a year now and doing well. Just wanted to thank you for the videos!

[@twitchizle]

"senior" is the new junior now huh

[@aaronalquiza9680]

@@twitchizle nah i've been a software engineer for 10 years but typescript was pretty new to me.

[@ArnabJhaYT]

Could you please tell me some niche technologies that I should learn to make myself unique in the job marketplace?

[@tacopito]

someone with years of experience, but learned and used a new language is still a senior😅, in big tech they work and learn tech stacks everyday and they are staffs not just seniors@@twitchizle

[@thomasstambaugh5181]

@@aaronalquiza9680 Typescript on Javascript reminds me of the relationship between Java and Smalltalk. The old joke about Java was "Java -- combining the blazing speed of Smalltalk with the elegant simplicity of C++". I've been avoiding Typescript while I work my head around current Javascript. I've only been doing serious JS coding for five years, so I'm still a newbie -- even though I've been doing OO development for decades.

[@cxarra]

The phone number analogy is a genius way to explain pointers. Never heard it explained like that before but I’m never explaining them any other way again.

[@santicanog_]

Stack and Heap's concept is clear with the analogy of the phone - and - phone number at 5:49. It was a great tool to illustrate what a reference is on the heap. Excellent teaching!

[@coder_one]

A recording that no one asked for, and everyone really needed. Thank you Jack!

[@incarnateTheGreat]

Haha I was just thinking about this. I think indirectly that people have been asking for this. The reason is because a lot of us are looking for work and are being challenged by asking about how JavaScript works. So, these videos are a welcome refresher. Thanks, Jack!

[@georgehamilton1166]

Never found such a video on KZbin explaining so much about how React works. In today's World where everyone is just writing code on the higher level and thinking that they are an Engineer, you really showed what you need to become a Principal Engineer. Please make more content about how React works under the hood so that we can build our own simple version of React some day🙃

[@meostyles]

Key takeaway: Use the references as indicators to react that the contents of an object or array have changed. In other words, they are immutable, so create a copy with the change you want to make, which will create a new object or array that is referenced. When react compares non-primitives by reference, it will see it has changed

[@bogrisss]

Brilliant!l content! And on top…, the edit, with the clean just text on black and floating you… impeccable! ❤

[@hamzahmd_]

I wish someone had taught me that clearly three years ago. JS and React are the most amazing things in frontend development if they're used correctly.

[@LongJourneys]

React is JS

[@qoobes]

Checked this out to see what kind of resources are available to people starting out today, as i've been doing this for a while, and WOW man. I wish i'd had this sort of thing when I was starting out, you're a saint!

[@rajgopal2513]

This is just mind-blowing, So many concepts learnt in just one video

[@kdev_007]

just what i wanted at 2:49 am. Thank you, Jack. Keep up the good work. Love and support from Bangladesh.

[@AK-vx4dy]

Second part of explanation should be mandatory to every "reactive" framework, great job !!!

[@vibemap9269]

Why doesn't the reactive framework, handle this as part of the dependency logic?

[@AK-vx4dy]

@@vibemap9269 I'm not expert in TS so... but I doubt it could be prevented by dependency logic. It could be handled in two ways... understand how your language really works or stick to the framework wich is less flexible and don't allow for different ways to do things. It is just curse of power wich JS and TS have as a languages.

[@EdwinMartin]

Good to know: most languages (C, Java, C#, Python) work the same way. When you compare objects/arrays, you compare the references.

[@nabinsaud4688]

Now nextjs memory leak issues needs to be solved too 😂

[@thomasstambaugh5181]

I gave up on nextjs and moved to vite. I've never looked back.

[@sphardegod5451]

​@@thomasstambaugh5181so u use vite with pure react? Not really nice to handle seo optimization with this stack

[@M1a2n3o43]

​@@thomasstambaugh5181 what about SEO and other benefits of nextjs like ssg ssr etc. i absolutely agree with you, nextjs sucks and i would want to go react only but as i said i hear react bad for that stuff and since i have little to no experience with SEO, what do you think? thinking about doing the same.

[@hatoke]

17:50 In the early years of my career, I used the JSON stringify function to obtain strings for such comparisons, and I used string comparison. I felt very clever at the time haha! It's funny to remember the strange code I used in the past.

[@mistersunday_]

Wow, glad you are back in my feed, haven't seen a video in over a year!

[@jherr]

Been posting them weekly. 🤷‍♂️

[@wishmeheaven]

The phones metaphor is brilliant.. Your educational content is always appreciated. Thank you

[@GuilhermePatriarca]

Love your approach... I have the feeling i m in a class, sometimes i answer your questions and you give feedback

[@0xSoko]

Might've had a follow-up interview if I'd seen this a few days ago 😁. Thanks for teaching us fundamentals in important use cases this was amazing.

[@fratut]

Hey, I think I remember you talking about this subject in a video a couple of years back, nice to see a refresh, it is a very important topic! :D

[@jherr]

I've covered it on and off, but never down to the stack/heap level. And I find myself having to explain it so often to folks that I wanted to have an actual video to refer back to.

[@fratut]

@@jherr Great idea, your work and energy is much appreciated 😄 I have learned a lot from you, keep up the great work and have a wonderful day 😁

[@vaibhavsanil]

Hi Jack, thanks for what you are doing for the community

[@foxrjver]

Some people have a talent to teach and you one of them!

[@kmlchannel]

Thank you, someone finally explained it clearly, and this helped me understand how it works.

[@kikevanegazz325]

The not-string-conversion-on-memory-loss tip blew me off. I thought it was a good idea when doing deep object comparison in order to avoid going one step deeper in another loop.

[@IncorporarMC]

i really like this kind of videos, because you explore in details how JS and React renders works! thanks!

[@jonathanhill7829]

Hands down the best video explainer of these concepts I've seen, thanks and 👏👏👏!!

[@BrianHutchison]

Great stuff, always good to have a refresher even if you know most of this already.

[@petrmotejlek1427]

Funny thing. I still found this valuable. Not really for me. But I think you were able to collapse a lot into a reasonably short video for a lot other folk :) Truth be told. I thought, based on the thumbnail, this will be about some quick/memory-efficient way to serialise objects :)

[@quintenbeek]

Hi Jack, love your videos. Just wanted to let you know there is a slight edit error around 17:24 learned a lot.

[@marianowadijacobo6252]

Great video, a must watch for any js dev!

[@rohitraj2321]

Never have i subscribed to a channel by lust looking at one thumbnail

[@ReubenQuinto]

New react developer here. Great video! I was definitely converting an object to string in an if statement to deal with async data. Thanks for the tips! Do you have any preferred tooling to identify exactly which javascript/react objects in your code is contributing to memory leaks/bad memory utilization?

[@pratikbankar4757]

Thank yiu Jack for such a thorough explanation. You rock as always.

[@lukerocco5523]

Thank you Jack Herrington! This is great content, well explained.

[@CodingAfterThirty]

Awesome video. Learned a lot.

[@darshilvaria441]

This is gold. Thank you Jack!

[@safehome-jdev1417]

Thank you, this was enlightening and easy to digest 🙏🏽

[@viruscerbero]

Hi there! First of all, this a great video (just like every other video you've done), thanks! I just wanted to comment that for strings there is an optimization done (by the engine). A technique called "string interlining" is used to store the same strings in the same location on the heap. That would explain how and why the same strings evaluate to equal. I learnt that from a Kateryna Porshnieva's presentation about memory management in JavaScript.

[@jherr]

That's good to know. My guess is the Object.is comparison for strings is probably; same pointer, falling back on same length, falling back on a byte compare.

[@AgustinAstronomy]

thanks for this amazing content, even with all the hate it gets, i love JavaScript and i will love always!!!

[@maliksuleman9474]

So knowledgeful. you have got a new subscriber.

[@shubhamlatiyan7972]

Most informative video on React and Js

[@virtuo-uk]

Excellent, thank you. This should highlight a lot of areas to refactor in a lot of people's projects. I think the graphics get a bit out of sync arounf 17:50

[@mortezatourani7772]

Great in-depth explanations.

[@neiker234]

Saying JSON.stringify is slow and that is the reason to avoid it is not telling the whole story. Even if it was fast, it can give incorrect results because the attributes can be in different order

[@jherr]

Interesting, I didn't know about the ordering thing, but it makes sense. Also JSON.stringify can't handle all types of data, or circular references (which are actually ok in some cases.)

[@buka.a]

I’d have to watch again cause I think I lost myself at some point

[@Erasser999]

Explained very well. Thank you.

[@thomasstambaugh5181]

Way cool. I've got a pretty good handle on the stack vs heap stuff (pun intended :)), and it's still tricky.

[@jherr]

Just let it mull around in your brain a little bit. Think about different types of structures in memory and how they are all linked together with references. It's a good mental model to fall back on when you have issues with data being written when/where it shouldn't be.

[@thomasstambaugh5181]

@@jherr Indeed -- I appreciate your attention. The issue I'm currently doing battle with is handling async/await inside a context provider. My frontend is a dashboard that uses a companion backend service (nodejs) to collect the data it manipulates. I use axios to connect the frontend to the backend, and I currently use async/await in the frontend to manage each exchange. I've created a "ToolStore" context provider at the base of the frontend containment hierarchy and my hope is to encapsulate all the async/await hair inside the ToolStore. In the fullness of time, I would love to see you do a piece on best practices for handling async/await (or its Promise chain analog) in a React context provider.

[@jherr]

@@thomasstambaugh5181 I'd have to understand more about how async/await is a problem there. But if you are getting back data from the backend that sometimes has the same contents as the previous fetch (but new references) and you want to avoid updates in that case, then simply do the comparison at the point when you are going to set the data and just avoid setting the data if only the references have changed. That way you only pay the cost of the comparison once. If you do that deep comparison work in the components then you are paying the cost on every render potentially in lots of places.

[@thomasstambaugh5181]

@@jherr Indeed, that's precisely the approach I'm working on. I'm currently keeping a "registry" object in the provider that maps each loaded "tool" (a tool is the frontend representation of a model object on the backend) to a string toolID. The code only calls the backend when a component asks for a tool whose id is not in the registry. The registry has at most a few hundred tools at any given time. I'm hoping that I don't need to go beyond a store/reducer combination like that in your "native-pokemon" example from a few years ago. I'm new enough to all this that I'm still struggling to ensure that each "tool" that the provider answers is a tool - as opposed to an unresolved promise for that tool.

[@rsousaj]

Amazing content as always!

[@aaryansj8016]

Thanks Sir 🙂 for valuable video 📸🎉😊

[@juanferrer5885]

Love to see a video about memory in JS, i would love to see more about memory, thank you Jack! So, we can store a strings that has +10000 charcters, and each time I pass that variable to a function its going to pass a copy of that, not the reference, why is JS doing that? Thats going to consume a lot of memory right?

[@jherr]

Technically speaking it's going to pass around a reference to the string. Strings are immutable though. So they are kind of their own thing. That being said, I wouldn't store structured data in strings by serializing and de-serializing them. It's going to negatively impact performance.

[@juanferrer5885]

@@jherr So if I have a variable like let one = "hello" let two = one two = "bye bye" Thats only going to mutate variable two, not one, because im passing the value of one. So if I have a long long string, and i pass to a function that string via props for example, I'm going to make a copy of that value, and reserve the same memory as before. in the hypothetical case that I store super long strings, It's better to store in a new instance of String? new String("hello") === new String("hello") // false In that case seems like string are going to be passed by reference instead of by value. So I'm going to use many bits of memory the first time that i store te super long string, but then I'm going to store only the reference, I'm right? I know it's a super weird case but just to understand memory.

[@jherr]

@@juanferrer5885 Try that first case for yourself. JavaScript is treating strings in all cases like primitives. So they have the same semantics as primitives. In your case setting `two` will NOT change one, because the semantics are not as a reference. But behind the scenes my strong hunch is that for the time that one and two share the same string value, they will be pointing to the same string in memory. But it's JS internals dependent and I wouldn't bet the bank on any implementation based on that. Just like I wouldn't bet the farm on tail call optimization, which is in some VM versions and not others. What I'm trying to do in this video is give practical understanding and rules of the road that will work across all JS VM implementations.

[@juanferrer5885]

@@jherr Oh, I see, thank you so much!

[@nillerbjj1]

Thanks Jack, great video. 👍

[@nomadmack]

Thanks Jack, now I have a better understanding.

[@IAmLesleh]

An interesting aside, Safari is the only browser to have implemented Proper Tail Calls for recursion. So if you code it so that the recursion is the last thing in the function, it won't create a new stack frame, it'll reuse the existing one.

[@jherr]

I was going to mention TCO, but I thought it was a bit of a rabbit hole. Safari implementing it is interesting since that means Bun would handle TCO as well.

[@rp77797]

Nice video, Jack. Curious how it works for rear query. Does the data object change on every load/fetch?

[@jherr]

Good question, I THINK react-query has a way where you can put some code into the process to get the result before it sets the data to make sure that the data has actually changed before the data reference has changed.

[@AsifHassanran]

Enjoyed your video every time! However, I couldn't stop thinking, 'What happened to your shoulder in the video?'

[@jherr]

Different shirt, and I hadn't adjusted the green screen software to compensate.

[@Elvis-is-king-l3s]

May I ask another question then. What if you pass a function in your dependency array. Then the comparison will return false. But what if the function passed is wrapped in a useCallback? What does it compare?

[@jherr]

useCallback is how you control function references in React. It's how you create a function inside of a component in a way that is compatible with dependency arrays and React.memo.

[@hoffmannfelipe]

Nice content! How about the React.memo when it comes to working with objects and/or arrays passing via props?

[@ryanz67]

I would love too see you do one on jest leakage 😄

[@dimakolyas916]

Hi Jack, Great content as always. Can you give us the link to the video that you talking about in the end of this video, about the impact of comparing contents vs comparing references?

[@jherr]

There is a card at the top of the screen that links to it but I'll save you the sweep: kzbin.info/www/bejne/oXfRoHdmZ8x0etU

[@bideshbanerjee5506]

Hoping for tuples in JS.

[@harikotha7]

Thanks Jack, Awesome content!!

[@zebraforceone]

Javascript _frees_ memory for you once it is sure you are done with it. In the mean time, it will quite happily allow you to allocate as much as you like until you run out.

[@jherr]

As will any other language, so, sure.

[@adevinwild]

this video is gold! excellent teacher

[@michaelbergen5982]

Thanks for your videos Jack! Great work as always. How would you recommend going about checking an array if the new state has different values than the old state but they both have the same length? Would it be acceptable in this case to stringify for the dependency array check?

[@michaelbergen5982]

For example, two elements removed and also two new elements added to the array in question. I guess maybe just storing a separate Boolean value hasChanges would be better? It feels messier than directly checking the value itself but seems it would be faster than stringifying even a short array. I guess stringifying also abstracts from the value itself anyway so maybe it’s fine. Anyone have any thoughts on this?

[@jherr]

No. The array should always change reference if its contents change. Just use something like `.with()` to return a new array with that index value changed.

[@jherr]

I think with the two element thing you are overthinking it. Think about it this way, dependency arrays are created on every render, right? So every time you render you want to stringify your data? That's a big cost. If you want to pay a stringify cost pay it when you set the data in the first place, which is far less frequent than a render: if(JSON.stringify(currentData) !== JSON.stringify(newData)) setData(newData);

[@michaelbergen5982]

I see. This makes sense. Thanks so much for the thoughtful response.

[@nourmustafa5094]

Great content, thanks a lot ❤

[@mohammedelmoutaouakkil]

Great tutorial Jack!

[@up.to.mountains]

What if we don't know the object fields? How to add it to dependency array without JSON.stringify ?

[@jherr]

You just depend on the object reference then, because anything in the object changes the object reference changes, that's the immutability contract that drives state in React.

[@fadfooood]

Amazing explanation 👏

[@rollotomasi1832]

Excellent video! 🎉

[@paweciosek489]

Great content! 👏👏👏👏 thank you! 🙏 ❤

[@sahajranipa]

Hi Jack I am very pleased with your awesome videos can you please make a detailed video about nextjs caching mechanisms it's very complicated it would be great if you make it easier.

[@jherr]

That will be in the NextJS course I'm building.

[@minnyanlin2051]

You are genius

[@russelldan554]

Do you have thoughts or suggestions on say wanting to use a deep equals in the use effect. Say i had an object with a bunch of form values and a useEffect I wanted to run if any of them changed. I have used react-fast-compare for this in the past but would love to hear your thoughts. Great video!

[@jherr]

I've got not problem with that. That being said, if I'm just depending on most of the stuff in the form data I'll just depend on the whole object. React was made to re-render, if it's not hurting performance I'm fine to re-render even if it's not strictly optimal if it reduces code complexity.

[@raphusnet1031]

Thanks for another great video

[@SamyarBorder]

Is there a limit to how many references we can make to objects in js?

[@jherr]

The maximum amount of memory allocated to JS VM over the size of a reference, probably a long integer plus the size of the smallest primitive, probably a boolean, but still a long integer. But not effectively, no. References are a core feature of JavaScript from day one. They are how the VM manages memory. Any additional feature you code in the VM is going to use references for implementation. The function that you create to try to work around references is itself going to have a references, and use references internally.

[@ibrohimbahromov1931]

Hello Jack, Great content! Your video makes me wander what would happen if React team decided to use intermediary object with value and integrity id properties to detect changes. On each state change call, they would update the integrity id hence providing reactivity for mutable objects as well. I haven’t actually thought about this long enough but just wanted to get your opinion. Thanks and keep up the good work!

[@jherr]

That would have been too much of a breaking change with the introduction of hooks. `useState` has the same semantics as `state` and `setState` from the class days. If `useState` were to use observables, or some other mechanism, that would have been too much change in a single go. Besides, observables have their own gotchas around arrays and objects. So I think the React team made the right call. That being said, a standardized `useStore()` that returned an observable, like Solid, would be cool. But there are lots of state management libraries out there and the new ones are pretty tiny so... just pick one of those.

[@bashhau]

Thx a lot really educative stuff. My question would probably be how is the old object garbage collected after the state gets assigned a new one?

[@jherr]

On the next free tick the VM will service the garbage collection. Anything with no references will be marked and eventually swept.

[@EwertonSilveiraAuckland]

Thanks buddy 🎉

[@arthurweasley5857]

Thanks, i just now have looked for all the places where I used json stringify in my current project and replaced it)

[@jherr]

Make sure that you control the references properly then, because if those were in dependency arrays that would cause more problems. Using JSON.stringify in a dependency array is just a symptom of a larger issue of not controlling references properly.

[@arthurweasley5857]

​@@jherr i replaced it as you said in the video - [data?.[0]?.value], I didn't want to do it before, cause I wasn't sure if this case would work for me in the future and cause re-render when it has to, but now that the feature is done, it should work as expected. Thanks for the video and the tip. i highly appreciate you and your videos)

[@jherr]

@@arthurweasley5857 And I highly appreciate your view! Thank you!

[@Siddharthpandey27]

One question though lets say you have to watch for complete object in dependency array so whats better JSON.stringify or using direct object reference

[@abdoufma]

If we're sending a new object/array instance every time we want to update the state, won't that also eventually cause a stack overflow?

[@vigneshwarrv]

No as old object/array would no longer have any reference, they will garbage collected and keep the stack and heap to the minimal.

[@evolopterus]

I've lost you on the JSON.stringify bit at the end.... you talk about stringify but the slide shows "Don't do this" on plain [data], which is different. I didn't see the "right thing to do" in the code. data?.count is not foolproof because the data may have changed while keeping the same count.

[@jherr]

Actually, data?.count is foolproof and correct because `count` is the only thing that is important to the logic inside the effect, and the effect should NOT be run if just data has changed.

[@evolopterus]

@@jherrIn the specific useEffect in the video, yes, count is the only thing that is required. But what if the effect cared about any changes to the data? Including a replacement of one of its values, which would not change the count.

[@jherr]

@@evolopterus Then you depend on whatever that is, or a combination of them if there are multiple dependencies. And if the they are primitives then when the values change the effect is scheduled to fire, and if you need the full object or array you depend on that, and when the reference changes that means the data changes. That's the contract. The alternative is to check the entire contents of the object or array on every render which hast the downside of potentially unlimited performance impact.

[@HilaryCheng]

Excellent video, JavaScript is hard to learn.....😅

[@jherr]

Hard, but also fun, right? Learning how it actually works under the hood is actually really cool and interesting. And now as you are building your app you can think about what's happening at a deeper level.

[@devwithbrian1534]

Thanks Jack

[@mj95412]

Great video

[@jherr]

Thank you soooo much!

[@AK-vx4dy]

Hi Jack, I didn't find section about leaks did I miss something?

[@jherr]

Sorry, no, I should change the title, it's more about memory management than memory leaks specifically. There is a small section on when the garbage collector runs after de-allocating when the last reference drops.

[@PS-dp8yg]

If tail call optimization was a thing in browsers, we wouldn't have problems using recursion. Unfortunately, the last time I checked, Safari is the only browser that supports tail call optimization.

[@jherr]

IMHO, not unless I had some way to verify that TCO was actually happening.

[@abdhelal]

Great content 😊

[@jony4you]

thanks, but if you say that comparison of two objects is a very slow operation, could you please provide some measurements? ) As I know if you compare obj1===obj2 than objects are compared by reference (memory location) and for smaller objects it can be faster than string comparison )

[@jherr]

I think you misheard me, I said comparison of strings is a slow O(n) operation in comparison to comparing object references which is very fast because you are just comparing two numbers.

[@BertVerhelst]

could you do a video about using native js libraries in react. like some component that manipulates the dom by itself and react should not rerender that div. but you still want to interact with it and use event listeners from the library to trigger state updates. I've come across the usecase for rich text editors or fancy video players or iiif viewers or leaflet maps. all of these have issues with updating when react changes state because they seem to live outside of the react framework. It would be nice to have some best practices for these and common pitfalls. ive tried avoiding rerenders by using useMemo and then use the js api of the library to force rerender when i detect changes in the ui. or i als tried just rerendering the whole component on every state change. but with rich text editors this can cause the component to rerender on each keystroke and it causes your cursor to jump to the beginning of the input field. so you actually type in reverse order. I've seen that issue on other tools as well like postman.

[@sagarkrishna14]

Thanks!

[@haythamkenway1561]

Hi Jack. what if we want to observe anything inside of an array or object. for example, we have 10 different property inside of an array of objects and we need to check if anything changes inside these objects. if any property changes. I saw you've mentioned creating a new array and not alter the main one for immutability reason. that's great, but can't it cause infinite loop? since we are comparing references, that means, it doesn't matter if the content changes or not, any time we create new object or array, it will trigger re render so the new reference will be created and on and on

[@jherr]

Then you depend on the nested object; `[topData.interiorKey]`. If interiorKey key has changes its reference should be changed. If it wasn't changed then the reference should remain the same. It's the same all the way down. If you make a change to a deeply nested object then all the references up to that object should be changed. But that's really not that hard: setData({ ...oldData, interiorKey: { ...oldData.interiorKey, updatingInteriorKey: { ...oldData.interiorKey.updatingInteriorKey, newValue: "foo" } } } Now only things that depend on data || data.interiorKey || oldData.interiorKey.updatingInteriorKey || oldData.interiorKey.updatingInteriorKey.newValue will fire.

[@internetexplorer7880]

I just json stringified an array yesterday 🤣

[@huynhhoai9697]

This is very interesting! But if I replace some values within an array, the array's size won't change. In this case, using data.count might not be the best way to track the changes

[@jherr]

The point of that useEffect is to track the array size, if it doesn't change then it shouldn't fire. If the point was to track the contents of the array (which it's not) I would depend on the array reference.

[@memeproductions4182]

@@jherr what if the array we depend on is a prop?would it change at every render making the useEffect useless?

[@jherr]

@@memeproductions4182 Same deal. The calling component needs to control the reference of the data it's sending. If it's something like an options object, then you need to depend on every key in the options object that the useEffect uses.

[@TJYouToob]

Excellent, must share... thanks!

[@dgoenka1]

whats your take on using object-hash (consider a case where we do need to make a comparison at the object level)

[@jherr]

I think using an O(n) operation to traverse the entire object to generate a unique hash on each comparison, versus an O(1) comparison between two long integers is not even a comparison. Just use references. It's how React was designed to work.

[@Sampathyemjala]

you are game changer .....

[@jaopreto-wlock]

fresh video...love it!

[@richardgeddes630]

What if you are dealing with very large objects and creating new copies of those objects, eats into performance? How about using an object property called 'version' ( a primitive ) and 'version' changes when the state of the object changes. Is there a primitive property in the prototype chain that can be used to detect object changes? At some point, doesn't creating new objects to detect object changes, invoke the garbage collector more frequently?

[@jherr]

... is not a deep clone. You don't usually need a deep clone unless your data is oddly structured. You use ... for a shallow clone of the top level keys. Those keys in turn are just copies of the REFERENCES to the nested objets stored in the heap.

[@vaibhavdn-builds]

This is gold