Thank you!

That is a good question. I was also using React for several years before learning how it actually works. I think it gives one some satisfaction to have a rough idea of how the technology that is being used works. Additionally, I think there are some practical takeaways, for example knowing how keys work and why they are important, etc.

I agree there is some satisfaction that I felt. And yes absolutely the thing with the keys is very important. I actually looked up some of my code and I found out I used the key incorectly: I used index as key 😱 {sectionsData.map((section, index) => ( <Container key={index} id={`section-${index}`} style={{ height: "100vh" }} > ... </Container> ))} But I guess this would be much more efficient (if the sectionsData changes like things get prepended for example): {sectionsData.map((section, index) => ( <Container key={section.id} id={section.id} style={{ height: "100vh" }} > ... </Container> ))} But do I really need to understand how the diff function works in order to apply that knowledge? I also could have just read this react documentation: Keys tell React which array item each component corresponds to, so that it can match them up later. This becomes important if your array items can move (e.g. due to sorting), get inserted, or get deleted. A well-chosen key helps React infer what exactly has happened, and make the correct updates to the DOM tree. Rather than generating keys on the fly, you should include them in your data: Pitfall You might be tempted to use an item’s index in the array as its key. In fact, that’s what React will use if you don’t specify a key at all. But the order in which you render items will change over time if an item is inserted, deleted, or if the array gets reordered. Index as a key often leads to subtle and confusing bugs. Similarly, do not generate keys on the fly, e.g. with key={Math.random()}. This will cause keys to never match up between renders, leading to all your components and DOM being recreated every time. Not only is this slow, but it will also lose any user input inside the list items. Instead, use a stable ID based on the data. Note that your components won’t receive key as a prop. It’s only used as a hint by React itself. If your component needs an ID, you have to pass it as a separate prop: <Profile key={id} userId={id} />. Source: react.dev/learn/rendering-lists Anyway now I started learning flutter and I wonder if flutter Widgets rendered as lists also need keys? I did some research and you can also provide keys in flutter to optimise re-rendering: www.flutterclutter.dev/flutter/tutorials/2023-04-08-how-to-use-keys/ But I think if I had read the react docs instead of understanding how this Diff function in react works I wouldn't have also assumed that in flutter there is a similar thing. So I don't understand how that knowledge of the react Diffing algorithm helps me. So maybe if you are trying to learn a similar but different technology maybe if you understand it in depth how the first technology works under the hood it may be helpful or may not? And I guess for static lists that don't change it's unnecessary to add keys. That's something I wouldn't have known if I wouldn't understand how the Diffing function in react works. So to summarise it is useful to have this deep knowledge for optimising and that knowledge can also be mapped to different technologies? Did I miss something? I still am not satisfied with my own answer. By the way if you could start learning React from beginning like someone would erase your memories and you would time travel in the past would you first just learn to "use" react for couple weeks and then start look into how it works under the hood or the other way around? @@PhilipFabianek

I agree there is some satisfaction that I felt. And yes absolutely the thing with the keys is very important. I actually looked up some of my code and I found out I used the key incorectly: I used index as key 😱 {sectionsData.map((section, index) => ( <Container key={index} id={`section-${index}`} style={{ height: "100vh" }} > ... </Container> ))} But I guess this would be much more efficient and avoid some bugs: {sectionsData.map((section, index) => ( <Container key={section.id} id={section.id} style={{ height: "100vh" }} > ... </Container> ))} But do I really need to understand how the diff function works in order to apply that knowledge? I also could have just read this react documentation: Keys tell React which array item each component corresponds to, so that it can match them up later. This becomes important if your array items can move (e.g. due to sorting), get inserted, or get deleted. A well-chosen key helps React infer what exactly has happened, and make the correct updates to the DOM tree. Rather than generating keys on the fly, you should include them in your data: Pitfall You might be tempted to use an item’s index in the array as its key. In fact, that’s what React will use if you don’t specify a key at all. But the order in which you render items will change over time if an item is inserted, deleted, or if the array gets reordered. Index as a key often leads to subtle and confusing bugs. Similarly, do not generate keys on the fly, e.g. with key={Math.random()}. This will cause keys to never match up between renders, leading to all your components and DOM being recreated every time. Not only is this slow, but it will also lose any user input inside the list items. Instead, use a stable ID based on the data. Note that your components won’t receive key as a prop. It’s only used as a hint by React itself. If your component needs an ID, you have to pass it as a separate prop: <Profile key={id} userId={id} />. Source: react.dev/learn/rendering-lists @@PhilipFabianek

Thank you so much!

There will be videos in the future, but I am sadly quite busy right now

Thank you!

Thank you, I am currently very busy but there will be videos in the future

In order to be converted make sure you have installed babel.

You are of course correct, but you could argue this way for pretty much all things in this video. All of the explanations are available at www.reddit.com/r/learnjavascript/comments/thuc7w/comment/i19vsmp/

I was trying to point out mainly the stuff that is not just the javascript stuff, there are 3 main rules in JS that cause all the weird stuff - rule 1 is everything except undefined is object, rule 2 is javascript first tries to do operation on objects themself, if unsucessful, than try to cast, and than throw error, and rule 3 I forgot while I was writing this, but I know there was one more important thing to remember :D