"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.

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!

Been posting them weekly. 🤷‍♂️

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 😁

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.

React is JS

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.

Fantastic! That's exactly why I made it.

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 you soooo much!

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.

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.

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.

There is a card at the top of the screen that links to it but I'll save you the sweep: kzfaq.info/get/bejne/oayeoqdhl82ldKc.html

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

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!

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.

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.

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.

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

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.

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!

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

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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.

As will any other language, so, sure.

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.

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.

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.

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.