Finally Fix Your Issues With JS/React Memory Management 😤

If you don't understand JavaScript memory management it's going to bite you over and over again. Let's learn it step by step so that you can have a solid grounding of fundamentals for your JavaScript, TypeScript, NextJS and React 19 journey.
👉 Upcoming NextJS course: pronextjs.dev
👉 Don't forget to subscribe to this channel for more updates: bit.ly/2E7drfJ
👉 Discord server signup: / discord
👉 VS Code theme and font? Night Wolf [black] and Operator Mono
👉 Terminal Theme and font? oh-my-posh with powerlevel10k_rainbow and SpaceMono NF
00:00 Introduction
01:15 JS Memory Management Simplified
07:04 How JS/React Compares Data
11:25 Applied Memory Management In React
18:58 Outroduction

[@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!

[@bogrisss]

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

[@IncorporarMC]

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

[@darshilvaria441]

This is gold. Thank you Jack!

[@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 😁

[@hgeldenhuys]

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

[@jherr]

Been posting them weekly. 🤷‍♂️

[@jonathanhill7829]

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

[@rajgopal2513]

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

[@stianmaurstad]

This is golden, thank you Jack!

[@0xmarkeljan]

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.

[@kmlchannel]

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

[@safehome-jdev1417]

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

[@hidden_monster007]

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

[@BrianHutchison]

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

[@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!

[@wishmeheaven]

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

[@vaibhavsanil]

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

[@pratikbankar4757]

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

[@rsousaj]

Amazing content as always!

[@marianowadijacobo6252]

Great video, a must watch for any js dev!

[@harikotha7]

Thanks Jack, Awesome content!!

[@mohammedelmoutaouakkil]

Great tutorial Jack!

[@Erasser999]

Explained very well. Thank you.

[@paweciosek489]

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

[@nigeryanes1987]

Thanks Jack, great video. 👍

[@fadfooood]

Amazing explanation 👏

[@nourmustafa5094]

Great content, thanks a lot ❤

[@mortezatourani7772]

Great in-depth explanations.

[@quintenbeek]

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

[@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.

[@rollotomasi1832]

Excellent video! 🎉

[@EwertonSilveiraAuckland]

Thanks buddy 🎉

[@lukerocco5523]

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

[@maliksuleman9474]

So knowledgeful. you have got a new subscriber.

[@CodingAfterThirty]

Awesome video. Learned a lot.

[@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

[@adevinwild]

this video is gold! excellent teacher

[@raphusnet1031]

Thanks for another great video

[@nomadmack]

Thanks Jack, now I have a better understanding.

[@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.

[@marcusviniciussilvaoliveir8559]

fresh video...love it!

[@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.

[@abdhelal]

Great content 😊

[@shubhamlatiyan7972]

Most informative video on React and Js

[@vaibhavdwivedi8660]

This is gold

[@aaryansj8016]

Thanks Sir 🙂 for valuable video 📸🎉😊

[@EdwinMartin]

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

[@sunilvishwakarma3941]

Awesome really today I got an idea why we are updating state in such a way

[@jherr]

Fantastic! That's exactly why I made it.

[@AgustinAstronomy]

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

[@devwithbrian1534]

Thanks Jack

[@TJYouToob]

Excellent, must share... thanks!

[@roycechriston5389]

Nice one

[@rohitraj2321]

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

[@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.

[@6_nikki_9]

killer video

[@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

[@michaeljarvis9541]

Great video

[@jherr]

Thank you soooo much!

[@williamcao5139]

GOAT

[@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!

[@hoffmannfelipe]

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

[@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.

[@webdeveloper2769]

You are a GOAT

[@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.

[@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.

[@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!

[@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.

[@buka.a]

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

[@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.

[@phonenaing8670]

thanks

[@kevinbatdorf]

JS doesn't pass by reference although it feels like it does. It passes a copy of the reference identifier. That's why you can't reassign it or null it. it's an important distinction I think.

[@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.

[@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.

[@bideshbanerjee5506]

Hoping for tuples in JS.

[@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.

[@MarcelRobitaille]

6:09 copying the object / array all the time would take a ton of time and a huge amount of memory 15:13: make a new object any time you want to change it

[@KevinOfSteel]

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.

[@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.

[@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.

[@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.)

[@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?

[@vigneshwarrv7136]

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

[@saeedkhazalvand4821]

Hello Jack , first much appreciation for your great content . I have a problem in my project , as I m new with node as a mern stack I m doin cha app project but I face with unexpected end of json input and set header sent to client . They are on my nerves , I can't expedite 😢

[@jherr]

There is a Discord server (link in the description) you can ask for help there. It's volunteer, please be respectful and read and follow the #rules.

[@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.

[@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.

[@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.

[@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.

[@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.

[@wjlee7003]

recursion won't always add to a stack each call. there are tail-call optimizations where it won't add it to the stack

[@jherr]

Yes, though if you read in the comments there is only one JavaScript VM that currently supports TCO and that's Safari. So you can't rely on TCO if you are writing portable JS.

[@ShaikSadiq-ov3de]

What if the the state object has a lot keys with different data types as values and I need to run the same useEffect when mutiple keys (way too many) change?

[@jherr]

Then just depend on the object itself. If any of the keys within an object change then the objet reference should be changed. If that's not the case then the issue is NOT with the dependency array, it's upstream, where the data is being modified improperly.

[@user-im6qz9nh7w]

What if your use effect dependency is an array of objects that is being passed as a prop and you only want to trigger the useEffect when 1 or more elements is added or removed from the array. Would using the ...oldValue work if you don't know what is being added (in this case I am using something like React Hook Form useWatch to get the array of objects from somewhere else)

[@jherr]

This is something you can't fix at the tail end, which is the component. The contract the component should have with the code that uses the component is simple; when the data changes then the reference should change. That is a fundamental principal of React code. If items are added, the reference should be changed. Removed? Reference change. Changed data without adding or removing? Reference change.

[@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.

[@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.

[@yogeshvanzara5553]

javascript string are by value but stored in heap ?? like const a = "jack"; const b ="jack"; console.log(a===b); it's true but it stored in heap so both reference will be same or different?

[@jherr]

Implementation wise they are stored in the heap. You can't detect that from inside JS though since the language and the VM hide that detail.

[@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.

[@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.

[@alimousavi329]

درود بر توی ای مرد بزرگ 👌

[@jherr]

متشکرم

[@omnilothar]

creating new object by spreading sometimes is difficult for nesting object. JSON.parse(JSON.stringify(data)) still do the trick?

[@jherr]

That is certainly one way to deep clone an object, but it has limitations in terms of the type of data it can clone. So beware of that.