This is funny; I literally dealt with this recently in a project. Figuring it out was frustrating because like others have mentioned, I had really only been using keys when mapping over arrays. I experienced all the emotions - disbelief, then anger (thinking I had found a bug with React), then frustration, then relief after adding keys, followed by confusion wondering whether I really should use keys - and after much research and digging around and seeing others do this, it made sense. Sometimes I think we miss some fundamentals while we “learn as we go”.
I think this is one of those edge cases we can't really account for. It may look simple, but we rarely need to do something like this, hence no one teaches it.
Literally had a discussion with a friend about the down sides of learning as you go. In my case it was modifying a rest api to process dynamic queries based on the POST object received from the client, so as to send only the requested data in the right format. Learning GraphQL in the first place would have saved me all that trouble. Learning as you go happens by default regardless. Learning actively has far reaching benefits without a doubt.
@@supercoolcat7692 The best way is to do both simultaneously, direct learning is too boring and difficult to understand, Learning as you go is easy to get stuck in the basic errors.
Interestingly, this is usually highlighted in reacts docs: 1. State is tied to a position in the tree 2. Same component at the same position preserves state 3. Different components at the same position reset state
Seems like a lot of people don’t like to read. I’ve seen it for React and other languages that actually have quite good docs for free. Seems like they’d rather pay for video courses…
@@exmachina767 Docs contain a lot of info about how the library works. Though an understanding of the language itself, in this case JavaScript is key, for someone to really gain insight from the docs. Otherwise, people want to copy and paste the solution.
Yeah, actually there are so many things we can learn from react docs. Even though somesone is senior react dev, i truely recommend reading all the react docs and api reference that updated all recently at least once.
Now I understand the purpose of keys in React. One important point you mentioned is that keys are mostly used in loops when returning JSX elements, and the compiler always warns us to use a key in such scenarios. Thanks to this video, I can now reuse the same component without encountering issues of conflicting distinctions.
Ever since I learned about how useful keys are in react it made my life easier, 'cause before I sometimes use useEffect just to get the behavior I wanted, and is prone to unnecessary rerender. I just saw it on TikTok. And yes, this is very useful in so many cases. Thank you Kyle.
What a piece of work the React, that's why it's happening. Tell us that Snow and Charcoal is exactly the same thing, and go on to tell how to fix this bug in _our_ code. We just need add keys to all of our code, no problem. Otherwise internal state of a component will no any binding to the component itself, and you completely messed up. Oh, we don't need to add keys to all of our code... But you need to guess, do the react knows is this chunk of DOM is the same than the other one or not. So better look better. Peace of beautiful work.
this is actually really important, as knowing reconciler algorithms helps to avoid so much pain one of the reasons why conditional rendering is a thing - it allows us to preserve positions {isTest && } } no matter what value 'isTest' is, Component's element will be on index-1, while index-0 is either false or same thing here - reconciler only cares about position and type. so if type and position is the same - it only updates that's why if you construct component type dynamically, you should memoize it properly (or use another approach tbh), cause if not your component will just keep re-mounting
Keys are fantastic. I learned the power of them a little bit ago from the (back then beta) new react docs, from the 'you might not need an effect' section. Basically immediately went and removed 10 useEffects, each ~15 lines long, just replaced them with initial state setters and keys. It was so nice.
I've had a series of sneaky bugs where data was persisting between pages of a dynamic react-router route, and fixed it with some workarounds. Turns out, adding a "key" actually solves all of them! Even better yet, I didnt go searching for this video. It just appeared in my recommended
I remember encountering this issue 3 years ago when I was building an inventory management system. Took me days to understand why the state was persisting across re-renders.
That's wild! I literally experienced this while working with a controlled select element yesterday. Read through a github discussion and learned that keys could reset my select for the next round of my app to do its thing. I didn't fully get it, but I was like "it is what it is". Then YT recommends this video to me a day later. How perfectly timed! I was basically primed to appreciate this video. Thanks Kyle, this was awesome.
I already knew this because of dart/flutter. It works absolutely the same way, with the same syntax too 😂 I think you could start a flutter channel too, cause dart is basically React + static typed variables with null safety.
This is enlightening! I guess this peculiar behavior comes from React's reconciliation mechanism, where React finds the React DOM node that's changed and then updates the changed node and its child nodes, while unchanged nodes and their child nodes remain intact.
im currently working on a project and i dealt with this and i just gave up on solving it really thank u u helped me alot and more ppl like me thanks again ♥
So do I, hooks are suposed to hold values between re renders, and if you change a parameter which is independent from the hook it has no sense to lose that state. Or at least this was the way i though it.
If you have read the docs on React's reconciliation algorithm this is explicitly pointed out. Keys are the things that help React bring down a o(n³) diffing algorithm down to o(n) To quote React docs "The state of the art algorithms have a complexity in the order of O(n3) where n is the number of elements in the tree. If we used this in React, displaying 1000 elements would require in the order of one billion comparisons. This is far too expensive. Instead, React implements a heuristic O(n) algorithm based on two assumptions: 1. Two elements of different types will produce different trees. 2. The developer can hint at which child elements may be stable across different renders with a key prop."
I was running multiple times on this issue but it was ok because React notify you on your browser elements should have keys haha except for the case early he was explaining, this can be tricky! well done :)
I think the warning only comes if you're mapping an array or something along those lines, a few days ago I had a problem involving the state of a child that persisted while the parent rerendered on new state. I solved it using a key in the child component and voila
Nice video. Good to shed some light on the internals of React's virtual DOM. Personally, this makes me so glad I don't use React for my personal projects.
Keys become really important whenever dealing with animations. And there it also becomes super clear how this works. I recently wrote a component that fades in a view and fades out another one at the same time, like a visual animated swap of components. Without keys properly set, animations would never work correctly. Good point again Kyle, thanks for bringing it up!
For React "isKyle ? : " is the equivalent of , so it would be mounted only once, and so the state. A stupid solution could have been putting a prop "isKyle" to Counter, and using a useEffect(() => setCounter(0), [isKyle]), so everytime Kyle state changes, the useEffect will be triggered, resetting the counter. The best solution can be using "key" as he said during the video. The solutions, sometimes, can be a lot, especially when the code becomes more complex as you go. But the "best" (better) solution can be known only when you deep understand what you are using (React framework, in this case). That's why you should always deepen your knowledge about a new framework/library/sdk/language, when start learning it, otherwise you will always be a "half developer", that will cause spaghetti code, bad maintained code, no extendibility, etc. I worked with people that didn't know about useMemo, useCallback and memo(), Suspense, Lazy, etc. and they didn't know how to use them. In big projects you risk to destroy the application performance, because you tend to use the solution that can work in that very moment. Instead, the best practice is always trying to create/find the best solution, thinking that can be reusable for other components, thinking that in the future the code can be changed, thinking that that code can be read by someone else. When you always try to do better, it will be easier for your brain to find the best solution for that problem, because you are training your brain to think Out of the box. Instead, if you find the cheap solution, your brain will always stay at the same level. Hope it helps to new programmers, or new React developers.
I had this exact issue last week with an array of components. I have they keys as the array index so they persisted when I changed the elements of the array. I worked around it a different way but now I know a much cleaner solve.
I encountered this bug before and resolved it by utilizing the useEffect hook, with 'name' specified as a dependency. Whenever the name changes, the counter restarts. However, it would have been great if I had known about this earlier. XD
0:21 i had something similar in flutter, where i was changing the rendering order of a few stacked widgets and they were behaving weirdly until i added keys
I know it's an old video, but man if most senior React devs don't know how to use keys that's scary. It was about the first thing I learned about React and it's damn close to impossible to program any complex app without it.
So I tried coding this with children and the issue persists I coded it as Kyle And Sally And I perform destructing {children} Then the counter component does the same thing as the video only I tied in a different way I thought since the children are different (p and h1) I thought it'll be a new state but I think react just sees that both times there's a Counter as parent and decided same state and moved on Damm Kyle I must say your the absolute best teacher when it comes to react. If I had known HTML, CSS, JS from before, I would've learned react from you and your course instead of taking a Udemy course that covered the html, css, js and react, Andrei Neagoie isn't as good of a teacher, you're the best teacher man
I'd say that this approach with using key is debatable. Counter could be reset by using useEffect, and overall this "bug" would not float up if code would be structured in different way. Theres no point to confuse junior developers with less known react features, when code can be simply restructured.
after 10sec the answer is key :) The learn react tutorial was really amazing and was covering this example. I suggest all new react learners to work trough the official react tutorials they are very good.
FYI: if use Vue, the same applies (you can use key outside v-for) I had the same problem with subsequent same components using v-if 2 years ago... and that was the solution
you could just have a useEffect within the counter which resets the count state on name change, this is expected behaviour afterall and would avoid a entirely new instance of the component because it just updates the state, also there no need to tenary the entire comp can just do that on the prop that makes it a bit less ambiguous. Using "useLocalStorage"(which btw is also a terrible idea because its a sync main thread operation which can be slow for big data blobs) it probs doing the above mentioned under the hood so you would not need any keys.
I can't think of a situation where I have used this setup and used the same element for both true and false so I'd argue it still works how you expect it to just in this specific case it has unwanted side effects
Thank you for this video. It makes me happy I skipped React and use Svelte 😂. Of course, sometimes we have to do assignments to force reactivity, so pick your poison. function addNumber() { numbers.push(numbers.length + 1); numbers = numbers; }
If you can’t fix that, you’re not a senior in React. It’s covered in the introductory documentation, and if you’ve built anything nontrivial you have come across a problem like this in one form or another.
Huh, can't say in 5 years I've ever encountered this but interesting nonetheless. Would've been nice to see you write out `` to drive the point home that all React sees is that Props changed, not the whole component. I absolutely would've expected React to figure this out on its own, but good to be aware of.
I’m pretty sure he didn’t do it that way cos he wanted to buttress the point that even though two counter components are rendered, react wouldn’t know which one to update
Well, as a kinda senior Vue dev I knew what the probelm is - it's quite common in Vue that when I render someting in similar way I need to key the components.
Got similar behavior on nextjs page change. where i was charging the order of list using msth random , but the ui wasn't updating because there were only image renders. it was working fine when i added some text in the item component
I wrap all my components in fragment or divs. or . I mainly do this in case i need to give a name to a div class but havent used it in a while. I wonder if this is why I never ran into this issue.
I've learned this the hard way. We've had a weird bug in our cart system whenever you edit the quantity of an item in a cart the item above it lose its quantity, this time we actually had keys which was relying on an id, the problem is the dev before me was extracting id from an object instead of _id so all items had undefined as a key which led to the bug..
But considering that the Counter component has different value in the "name" prop, why React doesnt re-render the component? Maybe it has to do with pure components?
Why not just use useEffect to reset the counter state when the props change? You wouldn't need to conditionally render or re-render the entire counter component anymore. Is there any benefit to doing it this way?
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
been using keys for a long time and this video has actually finally made me understand what they truly are
Same! As soon as he said the issue I exclaimed 'keys', it finally occurred to me what those were for
Same here!!
Same. I guess it's because I'm clueless about the virtual DOM
@@ghun131It applies to the normal DOM too.
Sad, but me too, 6+ years using react
This is funny; I literally dealt with this recently in a project. Figuring it out was frustrating because like others have mentioned, I had really only been using keys when mapping over arrays. I experienced all the emotions - disbelief, then anger (thinking I had found a bug with React), then frustration, then relief after adding keys, followed by confusion wondering whether I really should use keys - and after much research and digging around and seeing others do this, it made sense. Sometimes I think we miss some fundamentals while we “learn as we go”.
I think this is one of those edge cases we can't really account for. It may look simple, but we rarely need to do something like this, hence no one teaches it.
who wrote this code without a comment explaining an edge case is an total asshole.
Anger yes, we all do this
Literally had a discussion with a friend about the down sides of learning as you go. In my case it was modifying a rest api to process dynamic queries based on the POST object received from the client, so as to send only the requested data in the right format.
Learning GraphQL in the first place would have saved me all that trouble. Learning as you go happens by default regardless. Learning actively has far reaching benefits without a doubt.
@@supercoolcat7692 The best way is to do both simultaneously, direct learning is too boring and difficult to understand, Learning as you go is easy to get stuck in the basic errors.
Interestingly, this is usually highlighted in reacts docs:
1. State is tied to a position in the tree
2. Same component at the same position preserves state
3. Different components at the same position reset state
Seems like a lot of people don’t like to read. I’ve seen it for React and other languages that actually have quite good docs for free. Seems like they’d rather pay for video courses…
@@exmachina767 Docs contain a lot of info about how the library works. Though an understanding of the language itself, in this case JavaScript is key, for someone to really gain insight from the docs. Otherwise, people want to copy and paste the solution.
Thank you! I think the title is a bit hyperbole when its explicitly pointed out how keys work in docs.
@@wlockuz4467 I agree. This is one of the topics that is covered quite early in react docs. You don't have to dig deep to find it.
Yeah, actually there are so many things we can learn from react docs. Even though somesone is senior react dev, i truely recommend reading all the react docs and api reference that updated all recently at least once.
Never used keys outside arrays!! Thanks Kyle! It was quite helpful.
React community is so blessed having you, thank you, Kyle!
Now I understand the purpose of keys in React. One important point you mentioned is that keys are mostly used in loops when returning JSX elements, and the compiler always warns us to use a key in such scenarios. Thanks to this video, I can now reuse the same component without encountering issues of conflicting distinctions.
As a React learner, this was a very useful video
Thank you and keep doing the good work
Ever since I learned about how useful keys are in react it made my life easier, 'cause before I sometimes use useEffect just to get the behavior I wanted, and is prone to unnecessary rerender. I just saw it on TikTok. And yes, this is very useful in so many cases. Thank you Kyle.
It really helped me a lot to find out the "unique key props" errors in the react projects. Thanks a lot for your efforts as well.
Thank you! this is so clear and helpful.
I'm glad I was able to help!
What a piece of work the React, that's why it's happening. Tell us that Snow and Charcoal is exactly the same thing, and go on to tell how to fix this bug in _our_ code. We just need add keys to all of our code, no problem. Otherwise internal state of a component will no any binding to the component itself, and you completely messed up. Oh, we don't need to add keys to all of our code... But you need to guess, do the react knows is this chunk of DOM is the same than the other one or not. So better look better. Peace of beautiful work.
this is actually really important, as knowing reconciler algorithms helps to avoid so much pain
one of the reasons why conditional rendering is a thing - it allows us to preserve positions
{isTest && } }
no matter what value 'isTest' is, Component's element will be on index-1, while index-0 is either false or
same thing here - reconciler only cares about position and type. so if type and position is the same - it only updates
that's why if you construct component type dynamically, you should memoize it properly (or use another approach tbh), cause if not your component will just keep re-mounting
Keys are fantastic. I learned the power of them a little bit ago from the (back then beta) new react docs, from the 'you might not need an effect' section.
Basically immediately went and removed 10 useEffects, each ~15 lines long, just replaced them with initial state setters and keys. It was so nice.
Thanks for the tip
That's some gold nugget there! I didn't even know about how react treats the dom like that! Thanks I will definetly get your course now.
The new react doc explained this so well too. Cool video
Can u give link?
the video is pretty much a copy from official docs. still cool for people that dont like reading docs i guess
@@MrTomrocool for people that don't know how to read
I've had a series of sneaky bugs where data was persisting between pages of a dynamic react-router route, and fixed it with some workarounds. Turns out, adding a "key" actually solves all of them!
Even better yet, I didnt go searching for this video. It just appeared in my recommended
Best explanation about keys in react I've seen so far
I remember encountering this issue 3 years ago when I was building an inventory management system.
Took me days to understand why the state was persisting across re-renders.
This short video is actually very useful. I have a scroll position persistence problem in a project and this should solve that
That's wild! I literally experienced this while working with a controlled select element yesterday. Read through a github discussion and learned that keys could reset my select for the next round of my app to do its thing. I didn't fully get it, but I was like "it is what it is". Then YT recommends this video to me a day later. How perfectly timed! I was basically primed to appreciate this video. Thanks Kyle, this was awesome.
I'm really new to react and watch this yesterday and today I run into just this kind of problem but could now directly solve it. Thank you. 🙏
Thank you for publishing this. This tip has already helped me in multiple projects.
I already knew this because of dart/flutter.
It works absolutely the same way, with the same syntax too 😂
I think you could start a flutter channel too, cause dart is basically React + static typed variables with null safety.
That would be awesome, I really want to learn bloc in flutter.
@@cardel-qq6xp a lil bit controversial, but i love BLoC. Absolutely more than provider or riverpod
Flutter was inspired by React after all
Using key was my first idea of how to deal with this issue when I watched the intro :) Thanks for the useful video as always :)
This is enlightening! I guess this peculiar behavior comes from React's reconciliation mechanism, where React finds the React DOM node that's changed and then updates the changed node and its child nodes, while unchanged nodes and their child nodes remain intact.
im currently working on a project and i dealt with this and i just gave up on solving it
really thank u
u helped me alot and more ppl like me
thanks again ♥
If you had read react docs you would've solved even faster , do give react doc a good read you'll learn a lot
@@inkclusiveDesign thats true
im actually gonna start reading it all now
thanks for the reminder
@@oo-fv7sy Docs are so well written and structured, you'll love reading it
I fixed a bug at work today with this, about a month after watching this video, thanks! 🎉
😮 shocked so many people don’t know this. Well explained though. Always solid content! Knowledge is power 🎉
So do I, hooks are suposed to hold values between re renders, and if you change a parameter which is independent from the hook it has no sense to lose that state. Or at least this was the way i though it.
@@diosupremo4928 "hooks are suposed to hold values between re renders" can you please elaborate this statement?
If you have read the docs on React's reconciliation algorithm this is explicitly pointed out.
Keys are the things that help React bring down a o(n³) diffing algorithm down to o(n)
To quote React docs
"The state of the art algorithms have a complexity in the order of O(n3) where n is the number of elements in the tree.
If we used this in React, displaying 1000 elements would require in the order of one billion comparisons. This is far too expensive. Instead, React implements a heuristic O(n) algorithm based on two assumptions:
1. Two elements of different types will produce different trees.
2. The developer can hint at which child elements may be stable across different renders with a key prop."
I was running multiple times on this issue but it was ok because React notify you on your browser elements should have keys haha except for the case early he was explaining, this can be tricky! well done :)
I think the warning only comes if you're mapping an array or something along those lines, a few days ago I had a problem involving the state of a child that persisted while the parent rerendered on new state. I solved it using a key in the child component and voila
@@BRP-Moto-Tips yes this is exactly what I am talking about. Also, it doesn't come as a warning but as an error
Nice video. Good to shed some light on the internals of React's virtual DOM. Personally, this makes me so glad I don't use React for my personal projects.
Good for you!
Keys become really important whenever dealing with animations. And there it also becomes super clear how this works. I recently wrote a component that fades in a view and fades out another one at the same time, like a visual animated swap of components. Without keys properly set, animations would never work correctly. Good point again Kyle, thanks for bringing it up!
I don't think i have run into this yet, going to have to keep a lookout for this. Thanks!
For React "isKyle ? : " is the equivalent of , so it would be mounted only once, and so the state.
A stupid solution could have been putting a prop "isKyle" to Counter, and using a useEffect(() => setCounter(0), [isKyle]), so everytime Kyle state changes, the useEffect will be triggered, resetting the counter. The best solution can be using "key" as he said during the video.
The solutions, sometimes, can be a lot, especially when the code becomes more complex as you go. But the "best" (better) solution can be known only when you deep understand what you are using (React framework, in this case). That's why you should always deepen your knowledge about a new framework/library/sdk/language, when start learning it, otherwise you will always be a "half developer", that will cause spaghetti code, bad maintained code, no extendibility, etc.
I worked with people that didn't know about useMemo, useCallback and memo(), Suspense, Lazy, etc. and they didn't know how to use them. In big projects you risk to destroy the application performance, because you tend to use the solution that can work in that very moment. Instead, the best practice is always trying to create/find the best solution, thinking that can be reusable for other components, thinking that in the future the code can be changed, thinking that that code can be read by someone else. When you always try to do better, it will be easier for your brain to find the best solution for that problem, because you are training your brain to think Out of the box. Instead, if you find the cheap solution, your brain will always stay at the same level.
Hope it helps to new programmers, or new React developers.
Today this video saved my day (and my mental health). Thank you!
I had this exact issue last week with an array of components.
I have they keys as the array index so they persisted when I changed the elements of the array.
I worked around it a different way but now I know a much cleaner solve.
I understood the problem before the reveal. I feel special. :D
I encountered this bug before and resolved it by utilizing the useEffect hook, with 'name' specified as a dependency. Whenever the name changes, the counter restarts. However, it would have been great if I had known about this earlier. XD
This video helped a lot in clearing up another React nuance
Nice tutorial, really good explanation of what’s happening under the hood and some applications of how it’s used. Love it
I don't think it's senior-level stuff, but I understand that the clickbaity video title is good for the channel in general.
0:21 i had something similar in flutter, where i was changing the rendering order of a few stacked widgets and they were behaving weirdly until i added keys
I know it's an old video, but man if most senior React devs don't know how to use keys that's scary. It was about the first thing I learned about React and it's damn close to impossible to program any complex app without it.
Boosting careers out here, keep em coming Kyle we appreciate you very much man!
Very good explanation on how React uses the DOM.
We have that "issue" often with our icons. Thanks for your detailed explanation :)
This really helped me improve my mental model around keys in react. Thanks for the video❤
So I tried coding this with children and the issue persists
I coded it as
Kyle
And
Sally
And I perform destructing {children}
Then the counter component does the same thing as the video only I tied in a different way
I thought since the children are different (p and h1) I thought it'll be a new state but I think react just sees that both times there's a Counter as parent and decided same state and moved on
Damm Kyle I must say your the absolute best teacher when it comes to react. If I had known HTML, CSS, JS from before, I would've learned react from you and your course instead of taking a Udemy course that covered the html, css, js and react, Andrei Neagoie isn't as good of a teacher, you're the best teacher man
children are a prop passed to the Counter. So changing children is identical to changing other props (Except key)
@@robertsandiford6223 yea pretty much
@@adityaanuragi6916 not pretty much. The JSX compiler literally turns children into a prop.
@@robertsandiford6223 got it
Good vid!
One your most helpful ones (for me, at least)!
I'm glad to know I actually learnt this like 5 years ago...
I been doing react since early 2015, but great tip tho!
What plug-in are you using to get methods info and types? And code suggestion like minute 4:56 and 5:00
This is so helpful! Thank you so much for helping!
I always come here when I need to get smth quick fast 👍great work
I'd say that this approach with using key is debatable. Counter could be reset by using useEffect, and overall this "bug" would not float up if code would be structured in different way. Theres no point to confuse junior developers with less known react features, when code can be simply restructured.
I spent the whole day racking my brain over it and couldn't figure it out. Thank you! By the way, are you a wizard?
That is great explanation Kyle.
after 10sec the answer is key :) The learn react tutorial was really amazing and was covering this example. I suggest all new react learners to work trough the official react tutorials they are very good.
yea cool. Right out of ur awesome react course w arrays. Love it
FYI: if use Vue, the same applies (you can use key outside v-for)
I had the same problem with subsequent same components using v-if 2 years ago... and that was the solution
you could just have a useEffect within the counter which resets the count state on name change, this is expected behaviour afterall and would avoid a entirely new instance of the component because it just updates the state, also there no need to tenary the entire comp can just do that on the prop that makes it a bit less ambiguous.
Using "useLocalStorage"(which btw is also a terrible idea because its a sync main thread operation which can be slow for big data blobs) it probs doing the above mentioned under the hood so you would not need any keys.
Oh wow. This video is amazing! Thank you :)
You could also have an useEffect set the state back to 0 in the Counter component with the prop name as dependency
Even I thought of doing that but using useEffect will have an extra render when you set the state to 0
I watch your videos for such a long time that I said "..you have to use key" with you. Greeting from UHI in inverness.
Loved this, didn't know about it!🙌
I can't think of a situation where I have used this setup and used the same element for both true and false so I'd argue it still works how you expect it to just in this specific case it has unwanted side effects
Thank you for this video. It makes me happy I skipped React and use Svelte 😂.
Of course, sometimes we have to do assignments to force reactivity, so pick your poison.
function addNumber() {
numbers.push(numbers.length + 1);
numbers = numbers;
}
If you can’t fix that, you’re not a senior in React. It’s covered in the introductory documentation, and if you’ve built anything nontrivial you have come across a problem like this in one form or another.
Huh, can't say in 5 years I've ever encountered this but interesting nonetheless. Would've been nice to see you write out `` to drive the point home that all React sees is that Props changed, not the whole component. I absolutely would've expected React to figure this out on its own, but good to be aware of.
I’m pretty sure he didn’t do it that way cos he wanted to buttress the point that even though two counter components are rendered, react wouldn’t know which one to update
good topic, perfect explanation
Thank you so much! Your videos are gems!❤
You are really incredible man awesome keep going👌👌👍
Well, as a kinda senior Vue dev I knew what the probelm is - it's quite common in Vue that when I render someting in similar way I need to key the components.
Hey @WebDevSimplified, when is the course expected to come out?
Nice tip. Thanks.
If I could give a bazillion likes for this explanation I would! Big thx from a begginer
Nice deep dive, thanks
Got similar behavior on nextjs page change. where i was charging the order of list using msth random , but the ui wasn't updating because there were only image renders. it was working fine when i added some text in the item component
Very informative kyle. You are awesome
well done! Great Job bro!
I wrap all my components in fragment or divs. or . I mainly do this in case i need to give a name to a div class but havent used it in a while. I wonder if this is why I never ran into this issue.
wow this seems super useful!!👍
Such kind of use cases are rare, but they exist. I used manual keys once in 2017 and recently this year in April.
I've learned this the hard way. We've had a weird bug in our cart system whenever you edit the quantity of an item in a cart the item above it lose its quantity, this time we actually had keys which was relying on an id, the problem is the dev before me was extracting id from an object instead of _id so all items had undefined as a key which led to the bug..
worth watching. And it's a simple matter. But first time I come across keys outside the loop
it was great explanation. thanks!
Really good example! Keys are really powerful, feels like most people are just using them to fix the console warnings...
Great content, as usual, Kyle
Thank you, Kyle
If this isn't the best FE content chanel out there, IDK what is!
Very usefull explaination, keep going man.
wow it's really helpful video. thank you
I believe this is explained in the react docs in the section "Preserving and Resetting State", would not consider it a bug.
do you mind explaining how to reset state on a dynamic route with query params (both slug and query change) on nextjs?
I also was interested in how you made your useLocalStorage hook but sadly you didn't toggle the function body which I was waiting for.
Happy to know I knew the answer to this
There's this little Framework called Angular.
But considering that the Counter component has different value in the "name" prop, why React doesnt re-render the component? Maybe it has to do with pure components?
It does rerender, but state is persisted between renders of the same component
@@igorswies5913 how come?
Why not just use useEffect to reset the counter state when the props change? You wouldn't need to conditionally render or re-render the entire counter component anymore. Is there any benefit to doing it this way?
Or alternatively just pull the counter state up a level and pass that through as a prop as well
hence the reason using indices for keys can cause bugs, has to be unique consistent but indices can change if the elements are adjusted in an array.
How to make a senior backend dev feel junior again