Finally Fix Your Issues With JS/React Memory Management 😤
HTML-код
- Опубликовано: 28 май 2024
- 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 
Наука
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!
"senior" is the new junior now huh
@@twitchizle nah i've been a software engineer for 10 years but typescript was pretty new to me.
Could you please tell me some niche technologies that I should learn to make myself unique in the job marketplace?
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
@@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.
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.
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
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!
A recording that no one asked for, and everyone really needed. Thank you Jack!
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!
Brilliant!l content!
And on top…, the edit, with the clean just text on black and floating you… impeccable! ❤
i really like this kind of videos, because you explore in details how JS and React renders works! thanks!
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
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.
@@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 😁
This is just mind-blowing, So many concepts learnt in just one video
just what i wanted at 2:49 am. Thank you, Jack. Keep up the good work. Love and support from Bangladesh.
Wow, glad you are back in my feed, haven't seen a video in over a year!
Been posting them weekly. 🤷♂️
This is gold. Thank you Jack!
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!
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.
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.
This is golden, thank you Jack!
Hands down the best video explainer of these concepts I've seen, thanks and 👏👏👏!!
The phones metaphor is brilliant..
Your educational content is always appreciated.
Thank you
Thank you, someone finally explained it clearly, and this helped me understand how it works.
Great video, a must watch for any js dev!
Thanks Jack, Awesome content!!
Amazing content as always!
Thank yiu Jack for such a thorough explanation. You rock as always.
Great stuff, always good to have a refresher even if you know most of this already.
Hi Jack, thanks for what you are doing for the community
Now nextjs memory leak issues needs to be solved too 😂
I gave up on nextjs and moved to vite. I've never looked back.
@@thomasstambaugh5181so u use vite with pure react? Not really nice to handle seo optimization with this stack
@@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.
Thank you, this was enlightening and easy to digest 🙏🏽
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.
React is JS
Good to know: most languages (C, Java, C#, Python) work the same way. When you compare objects/arrays, you compare the references.
Love your approach...
I have the feeling i m in a class, sometimes i answer your questions and you give feedback
Great tutorial Jack!
Thanks Jack, great video. 👍
Some people have a talent to teach and you one of them!
Awesome video. Learned a lot.
Explained very well. Thank you.
Second part of explanation should be mandatory to every "reactive" framework, great job !!!
Why doesn't the reactive framework, handle this as part of the dependency logic?
@@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.
Great in-depth explanations.
Hi Jack, love your videos. Just wanted to let you know there is a slight edit error around 17:24 learned a lot.
Excellent video! 🎉
Great content! 👏👏👏👏 thank you! 🙏 ❤
Thank you Jack Herrington! This is great content, well explained.
Amazing explanation 👏
Great content, thanks a lot ❤
Thanks Jack, now I have a better understanding.
So knowledgeful. you have got a new subscriber.
this video is gold! excellent teacher
Thanks for another great video
Great content 😊
Awesome really today I got an idea why we are updating state in such a way
Fantastic! That's exactly why I made it.
Thanks buddy 🎉
fresh video...love it!
Thanks Sir 🙂 for valuable video 📸🎉😊
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.
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.
Most informative video on React and Js
Never have i subscribed to a channel by lust looking at one thumbnail
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?
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?
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.
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);
I see. This makes sense. Thanks so much for the thoughtful response.
thanks for this amazing content, even with all the hate it gets, i love JavaScript and i will love always!!!
Great video
Thank you soooo much!
Enjoyed your video every time! However, I couldn't stop thinking, 'What happened to your shoulder in the video?'
Different shirt, and I hadn't adjusted the green screen software to compensate.
This is gold
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?
There is a card at the top of the screen that links to it but I'll save you the sweep: ruclips.net/video/kFnoD02gADs/видео.html
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?
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.
@@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.
@@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.
@@jherr Oh, I see, thank you so much!
Nice video, Jack. Curious how it works for rear query. Does the data object change on every load/fetch?
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.
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!
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.
Nice one
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?
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.
Thanks Jack
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
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.)
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!
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.
Nice content! How about the React.memo when it comes to working with objects and/or arrays passing via props?
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.
As will any other language, so, sure.
Way cool. I've got a pretty good handle on the stack vs heap stuff (pun intended :)), and it's still tricky.
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.
@@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.
@@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.
@@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.
Thanks, i just now have looked for all the places where I used json stringify in my current project and replaced it)
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.
@@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)
@@arthurweasley5857 And I highly appreciate your view! Thank you!
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.
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.
I would love too see you do one on jest leakage 😄
killer video
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?
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.
What if we don't know the object fields? How to add it to dependency array without JSON.stringify ?
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.
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?
On the next free tick the VM will service the garbage collection. Anything with no references will be marked and eventually swept.
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.
That will be in the NextJS course I'm building.
I’d have to watch again cause I think I lost myself at some point
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?
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.
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?
No as old object/array would no longer have any reference, they will garbage collected and keep the stack and heap to the minimal.
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 )
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.
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
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.
You are a GOAT
whats your take on using object-hash (consider a case where we do need to make a comparison at the object level)
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.
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)
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.
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
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.
@@jherr what if the array we depend on is a prop?would it change at every render making the useEffect useless?
@@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.
thanks
is ok to use parse(stringify to deep copy and object? or there is a better way (regarding memory)?
It's fine. There are issues with it not being compatible with certain types of data, but that's a video for another day. I would NOT deep clone objects/arrays that aren't deep. And I would NOT deep clone unless it's really required. And I have seen deep cloning used as just a cheap way around not understanding references.
@@jherr thank you for the reply. I have this dashboard that gets data from the backend, and makes a copy of the object in order to check when there was a change on a parameter and send only that parameter to update to the backend after some period of time. looking forward for that video u mentioned tnx.
GOAT
Hi Jack, I didn't find section about leaks did I miss something?
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.
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?
... 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.
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 😢
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.
Is there a limit to how many references we can make to objects in js?
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.
creating new object by spreading sometimes is difficult for nesting object. JSON.parse(JSON.stringify(data)) still do the trick?
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.
Hoping for tuples in JS.
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.
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.
@@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.
@@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.
Excellent, must share... thanks!