Hey Max @academind thanks for this great video again. I already completed your React course a while back and I'm just catching up on the course update announcements. I am mind blown by these new lectures and projects you have added. I am thankful for your relentless efforts of keeping course content up to date and for free. Currently, I am actively job hunting for an opportunity as React developer and those new course projects are a great way to practice and refresh my React knowledge. Thank you
It's a dirty hack, not a good practice. You writting components, which cannot be used without key, and other dev's don't know about this required hack. And this absolutely terrible hack, when your component uses 3 or more props, which u need to hack with key. It's looks fine, but creates problems in future, when your project will grow. In case with a lot watching props, better choice to write useEffects, because any other dev can read and understand how it works, and he don't need to check all usages of this component for understanding.
@@ДмитрийКузнецов-р7и1т Using the key is the correct approach, but it belongs on the textarea element within the component - not on the component itself. It's not a hack either, just a way to bind the identity of the element to the state of the component; the new React official documentation explains it more deeply.
@@ДмитрийКузнецов-р7и1т it is not a hack, but expected behavior. The key changes so react knows to re-render the component. However I know from experience this does cause issues if you don’t know that it’s being used. I had an issue with my refs and states being reset and it was because the router path was being used as a key on my pages.
The localStorage example is kind of bad because it causes the localStorage to be accessed on every render. Use the function initializer of useState instead.
@@clintkennedy8387 This is a case where you do need useEffect. While it might be true that localStorage is synchronous, that's not the reason to move something away from useEffect. By moving it outside of useEffect or even in the function initializer of useState, you're doing side effects in the render phase. Doing so won't work if this component is ever expected to be used on the server as in with Next/Remix.
@@jasonfavrod2427 No It isn't redundant, because the default value of useState won't change, it always keep the default value that it has in the first render, that's when the key props comes into play.
Hello, dear Maximilian This video was suggested to me by RUclips and I watched all the videos. To be honest, I really like you and I missed you a lot and I was very happy to see another great tutorial from you. I hope you will always be successful.
Bro your god man;) I used to follow you since you were too much in angular. I subscribed your courses in angular but later I changed to React since I was tired brushing my self with new thing on angular every year and then I again moved to react after that I subscribed your courses in React I feel it’s heaven
You always helped me to learn at least one new item, as you told we always being around key concept , but never though it can be used to mitigate unnecessary use effect for state update 👍
18:10 wouldn't this now run everytime the component is rerendered? with useEffect with empty dependencies, it would only get run once and thats what we want?
17:15 the useState hook can alternatively take an initializer function, so you can also use that initializer function to get the required value from local storage. I believe its a bit cleaner this way because the logic of initializing the state stays coupled with the hook instead of lying somewhere else in the component.
@@chelseaGPT nope. As the name suggest, these are just initial values, so they're only calculated/set when the component first mounts. On subsequent re-renders, these values don't have any effect.
This is super critical. In his example the component was super simple and wouldn’t be rerendered many times. But if it had more state or props it would be getting from local storage multiple times for no reason
useEffect is the correct way to initialize a component's initial state with localStorage, since localStorage is an outside system, regardless of it being synchronous.
I feel quite good after watching this - as I am literally doing pretty much everything you have here. The additional thing I have is a directory full of 'services' which deal with those asynchronous calls to the various API's, e.g. Get SalesOrder/123 type stuff - which the useEffect calls in. I do also use these with localStorage stuff instead of accessing localStorage directly as that gives said service a chance to store that in a static (just a variable outside o the class) and also if I were to change the source of that piece of data I only need to swap the service implementation.
One thing I don't understand is why do you need to send the key? Your component will re-render again if any of your props change, so your computed value will be evaluated again anyways...
Furthermore, setting initial state in useState with an external API call makes the component impure. Calling a functional component with the same props should always return the same JSX.
Passing the responsibility to control re-rendering for the component using the component is wrong, each component should be de-coupled and the ones using it should not know the internals implementation to use it (other than the params), so the key thing and array find assuming you are keying the component is basically flawed
Yes, first things I thought about as well. Essentially user of the component should be aware of its implicit behavior at all times and remember to pass a key prop.
Long time ago somebody at FB made a wrong decision and pulled this react/render/state nightmare, and since then the whole world has been trying to figure out what to use and when to make something work which is not even designed for that. 😂
I don't really understand why passing a key to the TopicEditor is necessary. The TopicEditor is a child component of the Notes component, so when the selectedTopicId state in the Notes component changes, the Notes, as well as the TopicEditor component re-renders. As the Notes component is re-rendering it is going to pass the updated selectedTopicId to the TopicEditor component. Therefore the TopicEditor component will re-render with the updated selectedTopicId. If I'm missing something please someone should kindly point me to it.
12:24 that value computation runs on every render and it would get your app slow if that array is big enough. In that case wrap it in useMemo or wait for the new React compiler to ship.
For this specific case this is ok as component has only one prop. But yes, you are right. If in future some developer will add additional prop beside selectedTopicId, this dummy_topics.find will be invoked on each render. And in this case definitely const selectedTopic should be wrapped with useMemo. Good catch 👍
Yes, this guy has a good knowledge of technology but in this video he propagates bad habits)) He tries to save devs from making mistakes offering even more dangerous tricks. Although in this case his solution is good but abuse of this method can lead to performance issues
thanks a lot for the explanation. Please one question. @academind How do you manage to go so deeper in different subjects ? I mean diferrents you teach about like react, angular , docker , kubernetes etc...
Hey Max, I really appreciate your unique training strategies, I have studied a lot of courses with you and you are my number one teacher... By the way, In my opinion, we can use "useMemo" hook in the second sample (14:04) to set the "selectedTopic" value to prevent extra memory address definition in every render. Am I wrong?
The explanation on using a "key" is really nice, thanks for that!! Now I want to refactor all my useEffects. I'm curious to know if there's any difference between using a key or a useEffect in that case other than a key being a "neater" option?
Well, if you use a non-state value as a key then you can avoid re-render of the parent component and isolate the re-render to its child component which could greatly improve performance as it will not unnecessarily re-render the parent component and all of its child components.
Be careful as the localStorage example will cause a hydration error when using SSR, even when properly implemented, as the API doesn't exist on the server and it will cause a mismatch if the HTML we are rendering depends on the localStorage values.
commended!! i already knew about keys but cant find a way to use it. additionally it scope base, so it will not work outside the div if the child has a key too.
The component re-renders whenever a prop changes (a re-render doesn't reset a state to initial value), A component re-mounts when the key changes hence resetting the state. hopes that clears it.
Use useEffect if you need to do an operation that is not part of your React application, like a db call or data fetching, that's the best use case and they're both asynchronous
Should also use useEffect even for synchronous external APIs (like localStorage), since setting initial state directly through an external system makes the component impure.
The component re-renders whenever a prop changes (a re-render doesn't reset a state to initial value), A component re-mounts when the key changes hence resetting the state. hope that clears it.
You should memoize an object if you want to add it to a dependency array, although it could define the function within useEffect itself (or use useCallback to memoize it outside).
Hi Sir, Can you please do a full course for Jest no one has done a proper course for that with in-depth knowledge. Struggling in realtime projects like anything 😢
using keys is essential for efficient list rendering, especially when dealing with dynamic lists where items can be added, removed, or rearranged. While it's true that React re-renders components when their props or state change, using keys helps React identify which items have changed, been added, or been removed within a list.
when the key prop is changed react accepts as a new component appeared in virtual dom like it was not there before. So in other words it causes 'componentDidMount' not 'componentDidUpdate'
Thank you! It does feel like a religious movement and it's weird. I get people like ready query etc... but real world code still has use cases for use effect.
the last example you gave us still give error in nextjs because if you use localStorage inside the 'use client' it says localStorage is not defined so in nextjs you should use useEffect in that case I think. thank very helpful!!
Hey cool video! So recreating/"remounting" the component with a key is better then using useEffect? Won't it affect performance on a large component tree? If the component with a key recreation approach has a child component with its own state management, would not that state reset?
The new React documentation explains it better. The key is used for DOM element identity, and in the example, the text field needed to be cleared, which is not the default React behavior. So adding the key couples the DOM element to the state, which forces the element to be repainted when state changes. The documentation example is almost exactly the same situation as shown in the video here.
7:14 this explanation is not 100% correct. you don’t add it to the dependency array because that text const is not causing rerendering of this component. Even if text can change during runtime, you should not add it as a dependency.
Having a question here(ruclips.net/video/V1f8MOQiHRw/видео.html). You put the line(23) where you initialize the selected value before the line(24) where you initialize the enteredNote. In the react documentation it's mentionned that the hooks must comme first at the top of the function before other lines. What do you think about ?
The trick with the key is a stretch in my opinion. This approach puts the responsibility of "resetting" the component on the parent by providing the key attribute which is not required by the props. Don't you think this is a risky practice?
@@rafarkstudioYeah, the correct way to use the key is to go into the TopicEditor component and add the key to the textarea element. The prop is already being passed, so it'll be accessible when providing the key. The new React documentation shows the usage more clearly and with a detailed explanation.
@@nevermindmepls6773 If you wanna get a job, learn React or Angular. The other frameworks might be better for some situations but you don't have to worry about them when you are learning.
@@nevermindmepls6773 React is at this moment the most requested and popular library by companies, so if you learn react you will find jobs. Now if you want to learn something diferent, there is libraries like Solidjs that works better than Reactjs and is kind of the same logic, also vuejs, sveltejs, but these aren't as popular and demand as React.
Why useEffect on componentDidMount is worse then getting localStorage on every render? and why is even an extra effect bad? No much perfomance loses. Using keys is not good idea too because you move out critical logic out of component, better to incapsulate it inside and do clear state obviously. This is what any UI component actually DO>
useEffect is absolutely the right way to sync with localStorage, otherwise the component becomes impure. And the identity key should've been placed within the TopicEditor, on the textarea element.
You shouldn't be using that key trick. It causes components to remount, which breaks the performance and may cause the component/page blinks/jumps if it's big.
Using a key is a terrible idea as it cannot be enforced, hence your component depends on the attribute you are unable to control. And yes, you can define an interface, but not its implementation! You should never use this pattern.
Hi, Sir with real-time projects there are no courses jest React unit test cases with in-depth knowledge. So Can you please do one course on udemy sir will learn from u please....
Hey Max @academind thanks for this great video again. I already completed your React course a while back and I'm just catching up on the course update announcements. I am mind blown by these new lectures and projects you have added. I am thankful for your relentless efforts of keeping course content up to date and for free. Currently, I am actively job hunting for an opportunity as React developer and those new course projects are a great way to practice and refresh my React knowledge. Thank you
Max is always so passionate whenever he talks about programming. How can you not love this guy? 🤗
the (key) trick is really useful , thank you
It's a dirty hack, not a good practice. You writting components, which cannot be used without key, and other dev's don't know about this required hack.
And this absolutely terrible hack, when your component uses 3 or more props, which u need to hack with key.
It's looks fine, but creates problems in future, when your project will grow. In case with a lot watching props, better choice to write useEffects, because any other dev can read and understand how it works, and he don't need to check all usages of this component for understanding.
@@ДмитрийКузнецов-р7и1т Using the key is the correct approach, but it belongs on the textarea element within the component - not on the component itself. It's not a hack either, just a way to bind the identity of the element to the state of the component; the new React official documentation explains it more deeply.
@@ДмитрийКузнецов-р7и1т it is not a hack, but expected behavior. The key changes so react knows to re-render the component. However I know from experience this does cause issues if you don’t know that it’s being used. I had an issue with my refs and states being reset and it was because the router path was being used as a key on my pages.
The localStorage example is kind of bad because it causes the localStorage to be accessed on every render. Use the function initializer of useState instead.
Yep. He traded one problem for another.
@@clintkennedy8387 This is a case where you do need useEffect. While it might be true that localStorage is synchronous, that's not the reason to move something away from useEffect. By moving it outside of useEffect or even in the function initializer of useState, you're doing side effects in the render phase. Doing so won't work if this component is ever expected to be used on the server as in with Next/Remix.
The best explanation of a difficult topic on RUclips. Thanks Max🙏🏼
Thank you for this! That "key" trick was cool!
I think I don't get that part. Even if you don't include key there, that component will still re-render if the state was changed, no?
@@ZawCodes I believe that is correct. I see how the key could be useful to do what he mentions, but I figure it's redundant in his actual usage.
@@jasonfavrod2427 No It isn't redundant, because the default value of useState won't change, it always keep the default value that it has in the first render, that's when the key props comes into play.
Thanks for all the knowledge you share! I’ve learned so much from you for over a year now! 🔥
i found these videos of Maximilian so helpful and easily expained, thanks a lot!
Hello, dear Maximilian
This video was suggested to me by RUclips and I watched all the videos. To be honest, I really like you and I missed you a lot and I was very happy to see another great tutorial from you. I hope you will always be successful.
Bro your god man;) I used to follow you since you were too much in angular. I subscribed your courses in angular but later I changed to React since I was tired brushing my self with new thing on angular every year and then I again moved to react after that I subscribed your courses in React I feel it’s heaven
You always helped me to learn at least one new item, as you told we always being around key concept , but never though it can be used to mitigate unnecessary use effect for state update 👍
I can't undestand why you only have 3K of likes, thank you Max!
Finally you are out of Udemy and here on youtube. You the best
every time i delete a useEffect in our code base I feel a small celebration
Thank you for a topic and info.The "key" trick works for Vue too. It is a good reset for "cheap" components.
Finally someone with common sense!!! 👏👏👏(btw, that trick with the key to reset the state was cool! thanks!)
18:10 wouldn't this now run everytime the component is rerendered? with useEffect with empty dependencies, it would only get run once and thats what we want?
thanks for example with key - is amazing!
17:15 the useState hook can alternatively take an initializer function, so you can also use that initializer function to get the required value from local storage. I believe its a bit cleaner this way because the logic of initializing the state stays coupled with the hook instead of lying somewhere else in the component.
I want to ask a very basic question does initial values in usestate get computed when the component refreshes?
@@chelseaGPT nope. As the name suggest, these are just initial values, so they're only calculated/set when the component first mounts. On subsequent re-renders, these values don't have any effect.
This is super critical. In his example the component was super simple and wouldn’t be rerendered many times. But if it had more state or props it would be getting from local storage multiple times for no reason
@@Luis-fh8cv very fair point indeed.
useEffect is the correct way to initialize a component's initial state with localStorage, since localStorage is an outside system, regardless of it being synchronous.
I feel quite good after watching this - as I am literally doing pretty much everything you have here.
The additional thing I have is a directory full of 'services' which deal with those asynchronous calls to the various API's, e.g. Get SalesOrder/123 type stuff - which the useEffect calls in. I do also use these with localStorage stuff instead of accessing localStorage directly as that gives said service a chance to store that in a static (just a variable outside o the class) and also if I were to change the source of that piece of data I only need to swap the service implementation.
One thing I don't understand is why do you need to send the key? Your component will re-render again if any of your props change, so your computed value will be evaluated again anyways...
exactly
pretty helpful tutorial.
I spent some considerable time to read the official guide but this almost 20 minutes tutorial is lit.
It's very clear and important technique that can used to avoid some delays !
any update for you new angular 17 course?
Thanks Max! 🙇
localStorage is available only in the browser. so in useEffect was correct if you use something like next js, ...with server components
Furthermore, setting initial state in useState with an external API call makes the component impure. Calling a functional component with the same props should always return the same JSX.
Passing the responsibility to control re-rendering for the component using the component is wrong, each component should be de-coupled and the ones using it should not know the internals implementation to use it (other than the params), so the key thing and array find assuming you are keying the component is basically flawed
Yes, first things I thought about as well. Essentially user of the component should be aware of its implicit behavior at all times and remember to pass a key prop.
Long time ago somebody at FB made a wrong decision and pulled this react/render/state nightmare, and since then the whole world has been trying to figure out what to use and when to make something work which is not even designed for that. 😂
Thanks I think the useMemo should have been wrapped on topics finding if i am not wrong?
I don't really understand why passing a key to the TopicEditor is necessary.
The TopicEditor is a child component of the Notes component, so when the selectedTopicId state in the Notes component changes, the Notes, as well as the TopicEditor component re-renders. As the Notes component is re-rendering it is going to pass the updated selectedTopicId to the TopicEditor component. Therefore the TopicEditor component will re-render with the updated selectedTopicId.
If I'm missing something please someone should kindly point me to it.
definitely need more videos on how react keys work! awesome video
High quality content as always!
12:24 that value computation runs on every render and it would get your app slow if that array is big enough. In that case wrap it in useMemo or wait for the new React compiler to ship.
For this specific case this is ok as component has only one prop. But yes, you are right. If in future some developer will add additional prop beside selectedTopicId, this dummy_topics.find will be invoked on each render. And in this case definitely const selectedTopic should be wrapped with useMemo. Good catch 👍
Yes, this guy has a good knowledge of technology but in this video he propagates bad habits)) He tries to save devs from making mistakes offering even more dangerous tricks. Although in this case his solution is good but abuse of this method can lead to performance issues
Never start adding useMemo unless it actually is a performance problem. Use your profiler to determine if you should add complexity like useMemo.
Maximilian's udemy courses are also superb to watch, great guy
Love from India 🇮🇳🇮🇳🇮🇳
thanks a lot for the explanation. Please one question. @academind How do you manage to go so deeper in different subjects ? I mean diferrents you teach about like react, angular , docker , kubernetes etc...
Hey Max, I really appreciate your unique training strategies, I have studied a lot of courses with you and you are my number one teacher...
By the way, In my opinion, we can use "useMemo" hook in the second sample (14:04) to set the "selectedTopic" value to prevent extra memory address definition in every render. Am I wrong?
please any ETA for Angular 17 course ?
The explanation on using a "key" is really nice, thanks for that!! Now I want to refactor all my useEffects. I'm curious to know if there's any difference between using a key or a useEffect in that case other than a key being a "neater" option?
Well, if you use a non-state value as a key then you can avoid re-render of the parent component and isolate the re-render to its child component which could greatly improve performance as it will not unnecessarily re-render the parent component and all of its child components.
Reset state with keys 🔥thanks for sharing
Hi Max , Can I reset the react context inside useEffect ? Can I reset the state of component in that way ?
You absolutely can. Unless the state / context that you are changing is added in the dependency array of the useEffect.
Be careful as the localStorage example will cause a hydration error when using SSR, even when properly implemented, as the API doesn't exist on the server and it will cause a mismatch if the HTML we are rendering depends on the localStorage values.
Hi Max, excellent material, thanks.
I would like to know what tool you are using to create those orange squares to highlight something on the screen?
"Hey Maximilian , did you know that you are improving and enhancing people's knowledge by providing these types of videos?" 🥰
Really? I think that he doesn't know that, and actually he's doing the videos for his nanny to watch
Why in quotes? Are you AI?
No I'm not a AI.. , It is a Way of Writting Something and try to get Attention of SomeOne...
@@saurabhnegi3932but why quotes
@@saurabhnegi3932 That's exactly what an AI would say though....
commended!! i already knew about keys but cant find a way to use it. additionally it scope base, so it will not work outside the div if the child has a key too.
Best practices is what I need, for typescript, React, etc
Very elegant design and great job!
Thank you for your great content :)
Thanks Max! Thanks for all the money i made watching your tutorials as well xD
I don't get it, a component re-renders whenever one of its prop changes, I don't see the use of key, what is the added value ?
The component re-renders whenever a prop changes (a re-render doesn't reset a state to initial value), A component re-mounts when the key changes hence resetting the state. hopes that clears it.
Use useEffect if you need to do an operation that is not part of your React application, like a db call or data fetching, that's the best use case and they're both asynchronous
Should also use useEffect even for synchronous external APIs (like localStorage), since setting initial state directly through an external system makes the component impure.
15:14 but the id is already a props, why would i need to put it in the key props ?
The component re-renders whenever a prop changes (a re-render doesn't reset a state to initial value), A component re-mounts when the key changes hence resetting the state. hope that clears it.
@@shehrozmalik773 Thanks. I didn't know that.
Tlr, use key prop to force refresh on a comp ones
6:55 ok, but what should we do if we use object or a function? In this case the meaning of a dependency array disapears
You should memoize an object if you want to add it to a dependency array, although it could define the function within useEffect itself (or use useCallback to memoize it outside).
But sometimes the do not do it and do not mention why :) so it is the source of endless confusion@@TokyoXtreme
Will the key trick result in DOM updates?
Hi Sir, Can you please do a full course for Jest no one has done a proper course for that with in-depth knowledge. Struggling in realtime projects like anything
😢
really useful, thank you
5 star instructor for a reason 💌
I still don't understand why he used a key. Isn't it that every time a prop changes, the component re-renders. So why use a key?
using keys is essential for efficient list rendering, especially when dealing with dynamic lists where items can be added, removed, or rearranged. While it's true that React re-renders components when their props or state change, using keys helps React identify which items have changed, been added, or been removed within a list.
@@Zaheer__zk40 Thanks but it was just a generic description. Still don't answer my question.
@@arian5126his example sucked. Same key was passed as prop, so the key was redundant.
dont use AI to generate responses@@Zaheer__zk40
when the key prop is changed react accepts as a new component appeared in virtual dom like it was not there before. So in other words it causes 'componentDidMount' not 'componentDidUpdate'
Great video. Spot on guidance IMO.
PLease update the angular course max, pleaaaaaaaaase
Thank you! It does feel like a religious movement and it's weird. I get people like ready query etc... but real world code still has use cases for use effect.
the last example you gave us still give error in nextjs because if you use localStorage inside the 'use client' it says localStorage is not defined so in nextjs you should use useEffect in that case I think. thank very helpful!!
localStorage should be initialized through useEffect, otherwise the component becomes impure
I am glad brad traversy said it and i know longer have to question my sanity. React really does overcomplicate stuff.
future is vue
Still use React?
I’m waiting on that qwik framework course. Give it a shot. You’ve done almost all the frameworks already 😂
very helpful ! thanks Max :)
Great video 🎉
Hey cool video! So recreating/"remounting" the component with a key is better then using useEffect? Won't it affect performance on a large component tree? If the component with a key recreation approach has a child component with its own state management, would not that state reset?
You are right
The new React documentation explains it better. The key is used for DOM element identity, and in the example, the text field needed to be cleared, which is not the default React behavior. So adding the key couples the DOM element to the state, which forces the element to be repainted when state changes. The documentation example is almost exactly the same situation as shown in the video here.
Helpful, thank you!
JUST USE IT! haha Loved the video
Maximilian please also teach us examples of How to apply react using any AI api service like open ai or whatever
you need useEffect for localStorage if it is a NextJS project (SSR)
thanks for teaching us 😍
I thought I knew all about key prop.. this is a new feature for me)))
7:14 this explanation is not 100% correct. you don’t add it to the dependency array because that text const is not causing rerendering of this component. Even if text can change during runtime, you should not add it as a dependency.
The trick of key is not obviously and potentially it can make a big problem. I will not recommend to use for save state
Having a question here(ruclips.net/video/V1f8MOQiHRw/видео.html). You put the line(23) where you initialize the selected value before the line(24) where you initialize the enteredNote. In the react documentation it's mentionned that the hooks must comme first at the top of the function before other lines. What do you think about ?
Useful! Keep going with it
The trick with the key is a stretch in my opinion. This approach puts the responsibility of "resetting" the component on the parent by providing the key attribute which is not required by the props. Don't you think this is a risky practice?
I’m more worried about performance, the entire component will probably have to be mounted every time the key changes
@@rafarkstudioYeah, the correct way to use the key is to go into the TopicEditor component and add the key to the textarea element. The prop is already being passed, so it'll be accessible when providing the key. The new React documentation shows the usage more clearly and with a detailed explanation.
thanks
Weldone young man❤❤❤
Still using react??
could u tell me better alternative? starter at front, so wanna know smth better than react
@@nevermindmepls6773 If you wanna get a job, learn React or Angular. The other frameworks might be better for some situations but you don't have to worry about them when you are learning.
React + TypeScript
@@nevermindmepls6773 React is at this moment the most requested and popular library by companies, so if you learn react you will find jobs. Now if you want to learn something diferent, there is libraries like Solidjs that works better than Reactjs and is kind of the same logic, also vuejs, sveltejs, but these aren't as popular and demand as React.
@@nevermindmepls6773 if you want to build the most complicated UIs easily, react is the best options. own experience
Why useEffect on componentDidMount is worse then getting localStorage on every render? and why is even an extra effect bad? No much perfomance loses. Using keys is not good idea too because you move out critical logic out of component, better to incapsulate it inside and do clear state obviously. This is what any UI component actually DO>
Don’t get it either how getting state from localStorage on every render is better than doing it only once on mount.
useEffect is absolutely the right way to sync with localStorage, otherwise the component becomes impure. And the identity key should've been placed within the TopicEditor, on the textarea element.
Great one useQuery is better the useEffect 😊
You shouldn't be using that key trick. It causes components to remount, which breaks the performance and may cause the component/page blinks/jumps if it's big.
Didn't know Seth Rogen knew ReactJS.
please make a video about Nitro
Very helpful. Thanks
Using a key is a terrible idea as it cannot be enforced, hence your component depends on the attribute you are unable to control.
And yes, you can define an interface, but not its implementation!
You should never use this pattern.
You missed one major issue with useEffect... adding dependencies of objects and arrays.
It's only the trick. It make remount component instead rerender component
Well with React 19 useEffect it's becoming obsolete. The use() hook will take care of it
I am suprised that I already knew all the stuff.. I guess I am not a junior react developer anymore 😅
Hi, Sir with real-time projects there are no courses jest React unit test cases with in-depth knowledge. So Can you please do one course on udemy sir will learn from u please....
IDC. I want my Angular course! 😭
You are amzaing 💙💙
1.75x playback with Max. Every time. Good video tho.
Clickbait, useEffect is necessary 🤦🏻
🤔 He never claimed that it is not necessary. But there are many situations where useEffect is not necessary.
Thanks for saving time
Thanks
Thank you so much, it was very helpful❤❤❤
that is what the title tells, that is what click bait means.@@ChristianKolbow
2018 : Still using class components and lifecycle methods ? (functional components + hooks ftw)
2024 : Still using useEffect() ???
2028 : ???
As you say master =)