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!
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.
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!
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
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!
Never found such a video on TH-cam 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🙃
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!
@@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.
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.
@@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.
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?
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.
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.
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
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.
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.
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.
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.)
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 :)
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.
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?
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
@@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.
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.
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.
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?
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.
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.
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 😢
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.
Then the underlying array or object reference should change. Use the `with` method to modify a single element in an array and return a new array reference. It's very quick, even on large arrays. There is a LOT of FUD around about how copying data is evil. If you believe that you should stop using React entirely because components and JSX do TON more copying than your code will ever do.
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)
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.
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.
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!
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
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!
Never found such a video on TH-cam 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🙃
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
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!
Brilliant!l content!
And on top…, the edit, with the clean just text on black and floating you… impeccable! ❤
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.
This is just mind-blowing, So many concepts learnt in just one video
Good to know: most languages (C, Java, C#, Python) work the same way. When you compare objects/arrays, you compare the references.
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 😁
just what i wanted at 2:49 am. Thank you, Jack. Keep up the good work. Love and support from Bangladesh.
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.
Wow, glad you are back in my feed, haven't seen a video in over a year!
Been posting them weekly. 🤷♂️
The phones metaphor is brilliant..
Your educational content is always appreciated.
Thank you
This is gold. Thank you Jack!
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.
Thank you, someone finally explained it clearly, and this helped me understand how it works.
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?
Love your approach...
I have the feeling i m in a class, sometimes i answer your questions and you give feedback
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.
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.
i really like this kind of videos, because you explore in details how JS and React renders works! thanks!
Hi Jack, love your videos. Just wanted to let you know there is a slight edit error around 17:24 learned a lot.
Hi Jack, thanks for what you are doing for the community
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
Great stuff, always good to have a refresher even if you know most of this already.
Some people have a talent to teach and you one of them!
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.
Hands down the best video explainer of these concepts I've seen, thanks and 👏👏👏!!
Awesome video. Learned a lot.
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.
Great video, a must watch for any js dev!
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.
Thank yiu Jack for such a thorough explanation. You rock as always.
Thank you Jack Herrington! This is great content, well explained.
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.)
Thank you, this was enlightening and easy to digest 🙏🏽
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 :)
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.
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: th-cam.com/video/kFnoD02gADs/w-d-xo.html
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 for this amazing content, even with all the hate it gets, i love JavaScript and i will love always!!!
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.
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.
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.
Amazing content as always!
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.
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.
Thanks Jack, Awesome content!!
Thanks Jack, great video. 👍
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.
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
Nice content! How about the React.memo when it comes to working with objects and/or arrays passing via props?
Never have i subscribed to a channel by lust looking at one thumbnail
Explained very well. Thank you.
Great in-depth explanations.
this video is gold! excellent teacher
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!
Most informative video on React and Js
Thanks Jack, now I have a better understanding.
So knowledgeful. you have got a new subscriber.
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.
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.
Excellent video! 🎉
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.
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.
Thanks Sir 🙂 for valuable video 📸🎉😊
recursion won't always add to a stack each call. there are tail-call optimizations where it won't add it to the stack
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.
Great tutorial Jack!
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.
Great content, thanks a lot ❤
Great content! 👏👏👏👏 thank you! 🙏 ❤
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.
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.
I’d have to watch again cause I think I lost myself at some point
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.
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.
Amazing explanation 👏
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.
Thanks for another great video
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.
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.
Great video
Thank you soooo much!
You are genius
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.
I would love too see you do one on jest leakage 😄
fresh video...love it!
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.
Great content 😊
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.
IMHO, not unless I had some way to verify that TCO was actually happening.
Hoping for tuples in JS.
But what if I update a single element of the array? Then the length of the array will remain the same.
Then the underlying array or object reference should change. Use the `with` method to modify a single element in an array and return a new array reference. It's very quick, even on large arrays. There is a LOT of FUD around about how copying data is evil. If you believe that you should stop using React entirely because components and JSX do TON more copying than your code will ever do.
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!
Thanks buddy 🎉
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.