Thanks so much for watching! 🙏 Feel free to leave any questions in the comments below and I'll do my best to get back to you. 💌 Also be sure to subscribe to my newsletter to be the first to know when I release new content, and for exclusive content at jacquesblom.com
Awesome video! So many people are just writing the code without explaining the last little bit of why you have to call the render method in the end. Now I understood how it works! :D
I'm having trouble understanding why we need to freeze the currentIndex. Every time we re-render the App component the index would be set to -1 and then useState will be called twice. So, the call index would be 1 again. What is the point of setting the callIndex to -1 for every re-render? Could someone please explain it to me?
I'm just getting into React and i have this considerably naive question: why does setCount(countA + 1) works but not setCount(countA++) or setCount(++countA) ?
@@negenalamjiyn6637 now looking back after 2 yrs, and have better understanding of the JS closure, I think a more appropriate setState in this case should be `setCount(prevCount => prevCount + 1)`
setCount(countA + 1) works because useState doesn't change countA as many people think (and that's why you declare countA as a constant). It instead *re-renders* the component with a totally new countA variable that has a different value and a different memory address and destroys the old countA variable. Btw, setCount actually changes a variable that React creates internally under the hood and countA is just a copy of this variable that lets you read that variable's value but changing countA doesn't change that variable since countA is a copy. countA++ uses the *current* value of countA (means that setCount will use this value instead of the new one) and then *increments* countA by one. And since you're not passing a new value to setCount, the component won't re-render since React re-renders only when you pass a new value to setCount (in case of updating objects, you need to pass a totally different object to the setState function). If you have declared countA as a constant, you will get an error because you can't change the value of a constant (remember, setState doesn't change the variable but instead, it creates new one). If you have declared using let or var, the component won't re-render because only setCount is capable of re-rendering BUT countA will increment itself because it's declared using let/var and it will cause bugs when re-rendering. For example, if you click the add button, it will increase countA but it won't re-render and hence the user won't see the new value so countA will become 1 but on the page, it will be 0 and that's because setCount was passed the old value and hence, no re-render and then countA will become 1. However, if you click button for the second time, countA will become 2 but setCount will get 1 and then compare the new value with the value stored in React's memory (which is 0). Since they're different, setCount will cause a re-render and countA will become 2 and on the page, the user will see one since setCount received 1 as a value. ++countA is the opposite. It first increments and then pass the new value to setCount BUT since countA is a constant, you can't increment it and you will get an error. If you have declared it using let/var, it will work like setCount(countA + 1). Why? Because ++countA, as I said, increments countA first and then pass the new value to setCount. And since it's a new value, setCount will re-render the component with a new countA variable. I've tested this and it didn't cause bugs but you probably shouldn't use it. Correct me if I got anything wrong.
@@youarethecssformyhtml that seems about right. And that, is also why there’s a good practice to use the `const` declaration in React code, since it adheres to the “re-render” behavior of the library. But that doesn’t mean we should never use `let` or `var` though, they still have their places in helper functions where we want a variable to survive through the scopes of code blocks ;)
He is right. At 2:00 he should declare the index and the array outside the useState function because they are global and common over the multiple calls of useState. If inside, then they will be re-initialized each time the useState is called, which is wrong.
Thanks so much for watching! 🙏 Feel free to leave any questions in the comments below and I'll do my best to get back to you.
💌 Also be sure to subscribe to my newsletter to be the first to know when I release new content, and for exclusive content at jacquesblom.com
Finally someone was able to explain this well!
One of the most interesting videos that I have ever seen.
Why do you only have 1.5k subs? This was so interesting. Thank you.
This is not what I was looking for, but i am very thankful this much clearity of explanation. Really appreciate.
I watched more than 3 videos and admittedly this is the most elegant code ever!
Awesome video! So many people are just writing the code without explaining the last little bit of why you have to call the render method in the end. Now I understood how it works! :D
too good😲 never had such deep dive into react, will definitely check the recoil content now
Thanks, Sourav!
Great video, helps understand certain things many devs might take "as given".
Amaziiiiiingggg!!!! Thanks Jacques..so insightful!
Dude u got very good presentational skills. U will rock. keep posting videos.
Really wonderful!! Helped me in a state of confusion
Great video we have just seen Great content creator
Awesome ❤️ Subscribed.
This is a great video, very well presented, thank you so much!
Very interesting
thanks so much. very useful information
Why does calling "renderApp" work inside setState? Aren't function expressions not hoisted? Or does it reside in memory after the first "render" ?
I'm having trouble understanding why we need to freeze the currentIndex. Every time we re-render the App component the index would be set to -1 and then useState will be called twice. So, the call index would be 1 again. What is the point of setting the callIndex to -1 for every re-render? Could someone please explain it to me?
Thanks 😊 I also follow you on Learn Recoil and the way you explain make it thinks look easy-going.
Thanks so much, Michel!
Super!! Very useful
does ur useState accept prev=>prev+1 ??
That was pretty dang explanation
I'm just getting into React and i have this considerably naive question: why does setCount(countA + 1) works but not setCount(countA++) or setCount(++countA) ?
Still don't know or should I explain as I understand?
@@negenalamjiyn6637 now looking back after 2 yrs, and have better understanding of the JS closure, I think a more appropriate setState in this case should be `setCount(prevCount => prevCount + 1)`
setCount(countA + 1) works because useState doesn't change countA as many people think (and that's why you declare countA as a constant). It instead *re-renders* the component with a totally new countA variable that has a different value and a different memory address and destroys the old countA variable. Btw, setCount actually changes a variable that React creates internally under the hood and countA is just a copy of this variable that lets you read that variable's value but changing countA doesn't change that variable since countA is a copy.
countA++ uses the *current* value of countA (means that setCount will use this value instead of the new one) and then *increments* countA by one.
And since you're not passing a new value to setCount, the component won't re-render since React re-renders only when you pass a new value to setCount (in case of updating objects, you need to pass a totally different object to the setState function).
If you have declared countA as a constant, you will get an error because you can't change the value of a constant (remember, setState doesn't change the variable but instead, it creates new one). If you have declared using let or var, the component won't re-render because only setCount is capable of re-rendering BUT countA will increment itself because it's declared using let/var and it will cause bugs when re-rendering.
For example, if you click the add button, it will increase countA but it won't re-render and hence the user won't see the new value so countA will become 1 but on the page, it will be 0 and that's because setCount was passed the old value and hence, no re-render and then countA will become 1. However, if you click button for the second time, countA will become 2 but setCount will get 1 and then compare the new value with the value stored in React's memory (which is 0). Since they're different, setCount will cause a re-render and countA will become 2 and on the page, the user will see one since setCount received 1 as a value.
++countA is the opposite. It first increments and then pass the new value to setCount BUT since countA is a constant, you can't increment it and you will get an error. If you have declared it using let/var, it will work like setCount(countA + 1). Why? Because ++countA, as I said, increments countA first and then pass the new value to setCount. And since it's a new value, setCount will re-render the component with a new countA variable. I've tested this and it didn't cause bugs but you probably shouldn't use it.
Correct me if I got anything wrong.
@@youarethecssformyhtml that seems about right. And that, is also why there’s a good practice to use the `const` declaration in React code, since it adheres to the “re-render” behavior of the library.
But that doesn’t mean we should never use `let` or `var` though, they still have their places in helper functions where we want a variable to survive through the scopes of code blocks ;)
🎉
At 2.00 why are you declaring outside the function why not inside the function?
He is right. At 2:00 he should declare the index and the array outside the useState function because they are global and common over the multiple calls of useState. If inside, then they will be re-initialized each time the useState is called, which is wrong.
i can't understand. so fast for me
Doesn’t usestate use closures