React's own docs explicitly recommend using state-controlled inputs over refs whenever possible. It refers to the ref method as "quick and dirty" because it lets the DOM handle tracking the value instead of React, which can sometimes cause unexpected behavior when React renders its virtual DOM. So... yeah. I think for forms, especially large ones, it's better to keep track of values in a single state object with key-value pairs. That does mean it'll re-render whenever a value changes, but since React only manipulates the DOM for the one input that's changed, it's not a big deal; and it allows React to have more control over, and more understanding of, the inputs, for optimizations. The main issue with using local variables instead of useEffect for composite values is future-proofing: when you add more state to the component, those variables will be re-evaluated on every re-render even if they don't need to be. In such cases, I think useMemo is the optimal solution; in fact, it's why useMemo exists! (And I believe recomputing a memoized variable doesn't trigger a re-render the way setting state does, though I couldn't find anything definitive about that.) But you are right that in some cases, you don't need to listen for changes at all, since you can just use the new value at the same time as you're setting it on the state.
I think useRef should be used for forms, you don't want component re-rendering on every key stroke just for a form, but if you was using a search/filter input where you are filtering on the users key stroke then you would need to useState and make it a controlled component.
@@chonmon it's not a big deal but if you can avoid any components from rerendering no matter how small is just a bonus. Also it's less syntax in that component, which looks nicer
@@SahraClayton then you can opt for other event like submit or blur to minimize re-render. Although useRef is a fine solution since there’s no re-render, using it with forms that have many fields or require validation will give you a hard time managing these fields’ value and their behaviors
A good thing to point out about the first mistake is that a good UX informs the user if the field has any errors while they are typing; in this case, this is not possible. Better to stick with states, but it is a nice thing to know.
some of the senior developers in a company I worked for used to not approve my PRs asking for me to not use useRef to the store any state in react component. It is nice to see someone explaining why not every state needs to be rerendering the component on every data update.
Using refs instead of state does not seem right in this scenario. First of all, such a render does not create any overhead since behind the scenes react will do equivalent of what you have done with refs. Besides, these code will probably be improved with validators etc. which will result going back to state version
You're correct. React has always preferred controlled components (react handles input value) over uncontrolled components (DOM handles input value). This is second time I see Kyle making this counter-argument to use refs, which I think is incorrect.
This is really debatable, as the scenario Kyle mentioned is that, all the inputs are only used upon form submission. For experienced React developers, we have always been using controlled components and get really used to it, so we are very unlikely to use Kyle's uncontrolled ways in any circumstance.
@@ACMonemanband True. Refs are mentioned in the "Escape hatches" section in the new react docs, which for me intuitively tells that refs are used as secondary option when first option of controlled components doesn't work.
@@ACMonemanband These days I usually just use react-hook-form and don't worry if something is controlled or uncontrolled in a most forms. The fact is that for more complex forms that might compute a lot of stuff, uncontrolled form inputs are better because they won't re-render the whole form on each input change. If you need to do any active validation, you'll probably have to go for controlled forms because you'll have to react to form changes all the time and not just on submit, but in cases where you just need to validate on submit, you probably want to go for uncontrolled inputs. Only reason I dislike his input ref example is because you'll rarely only work with two field forms in the real world and you'll most likely have multiple (more complex) forms in your app. At that point, just reach for something like react-hook-form and never worry about building forms in React.
Hey Kyle, This is really very helpful for me. Tomorrow I have a task to complete in my office. I was worried about how to do that. but, this video gave me a clear idea about that. Thanks a lot. Keep going, bro. Loves from Sri Lanka ❤
This was a great video and helped me solve an issue i had with my hook, namely having multiple states update with an action needed once they were both updated. it took a while to wrap my brain around it, but this video really helped give me the vision. love your videos and that you go super in depth (in the longer ones). probably the best coding tutorials on youtube. if i ever get my web dev dream job, i will be getting you a few coffees/beers.
Man, using setCount( (count)=>{count + 1} ), it's the greatest way how to handle this real react problem! That's was extremely beneficial for me !!!!! Thank you!
Very clear video, I just switched to Typescript for last major project, took a bit of effort initially but rewards are great, the build step catches a good few errors very early. I think not using TS could be added to your list. I expect many that haven't given it sufficient time will disagree.
I spent hours on my degree final project sorting out errors that js didn't pick up until I tried to run a piece of code with an error in. Switched to TS and it's a million times better and Id also say I've learnt a lot more too
Yes that is what I usually do. const formData = new FormData(e.currentTarget) and then const [username, password] = [formData.get("username").toString(), formData.get("password").toString()]; looks cleaner to me than using refs or state there well I still use state for input validation though
Thank you for the great video! Regarding the choice between useRef and useState for form submission, I believe we should use useState instead of useRef. This is because we typically need to reset the input value to empty after submission. For input filtering, updating the state as the keystrokes change is necessary to display the latest value in the UI.
Fantastic! I’m just learning react and you’ve explained the funky behaviour I’ve been getting with useState perfectly. Thanks for taking the time to make these videos 😊
15:45 in that case instead of useMemo we can directly use in the dependency array person.name and person.age and it will not cause rendering when you change the dark mode checkbox
if you want to use the AbortController, but you are fetching data in a function, instead of in a UseEffect. The way i do is, use a UseRef to save your AbortController, use controller.abort() in the beginning of the function , then create a new controller and assign it to ref.current. pass the new signal to the fetch and voilà.
You really have a talent for education my man. Whenever I'm not understanding something in web dev now I just search for web dev simplified and boom there's always a video on it. Thank you! These were really good tips for those of us just getting into front end :)
That last useFetch insight is very helpful! I think it could be even more so if combined with some king of debounce? So the fetch only runs after say 0.5s?
Interesting video Kyle! I noticed I do make a few of these mistakes myself. I think the problem is that us developers can be a bit "lazy" learning new frameworks. I understand how the useState and useEffect hooks work and I never took the time to learn about useRef and useMemo for example.
if its a simple form then you can just take the values from the form event when you submit and you dont really need to keep state provided you have a vary basic use case for the form, complex validations and connected models then you'll probably go back to using state
Good video. One tip: if the arrow function will return an object, you can just put the object inside parentheses instead of using a full code block with a return keyword. Example: () => ({ age, name }) Also I believe you can simply return controller.abort instead of returning an anonymous function which calls controller.abort()
Would you be able to explain to me what is being passed to currentCount at around 6:00? Does calling setState automatically pass in the current state as an argument? Not sure how else it would be possible since the parameter name seems to be arbitrary, ie prevState. It sounds like you know your stuff, any help would be appreciated!
@@billynitrus setState accepts a function which its parameter (currentCount) is the value of ‘count’ before being updated. Ex. If count is 9 and you clicked on the ‘+’ button ,if you try to log ‘currentCount’ you would get 9 ,thus ‘return currentCount (9) + amount(1)’ will result in updating ‘count’ to 10
How are you able to console log d at 11:40 but not console log count at 6:55 ? I thought you said setting state happens asynchronously. Can someone explain the difference?
This was soo helpful. I had a beginner project, just for fun and I almost made all of the mistakes. I just fixed my code, and it looks much better now. Thank you
all good, but actually, 20:09 when you cancelling controller will throw AbortError so catch and finally functions will be run. I guess in that case we want check for AbortError and not set this error )
How do you deal with forms that are using dynamic data.. they are created dynmically. Is there a way to add each input add to a ref object or array of some kind for a similar effect? cant really add individual varaibles due to the way each element is added to the form.
First example is iffy advice for beginners. They won't be able to discern when they can get away with refs. It's better to use state by default because it's reactive. Going straight to refs is premature optimisation. What if your form has fields that should conditionally be shown depending on the value of other fields? You need to re-render. It's a pretty common case. The first useEffect example is so spot on though. I see that all the time. And the referential equality problem is so subtle but so important to note! Nice work.
Hey, how come full names gets the updated value? Isn't state async and by the time it gets to the const full name we might not have the updated first and last name?
You are wrong about using useRef for managing form values. It's even mentioned by one of the react developers at Facebook. You can even find this in the react beta docs. useRef is overly used by people who have used Vue js before. Well, react is different than Vue js
if you are so sure that your url changes very quickly after another, I prefer using debounce instead rather than executing and canceling a fetch.. no request is faster than a cancel and re-request, canceling doesnt work if your API runs fast enough
In the first example when you simplify the input values with useRef() and onSubmit().. at that point .. could you not just destructure the values from the submit event itself? I wonder if theres another example that could work more effectively?
{} === {} false is the correct result for more than one reason but what I want to stress is that {} is NOT an object, it is the LITERAL CONSTRUCTOR hense don't tide the symbols to what they actually are, the constructors return objects. Excellent video ty.
1 question. So, when i do useState i can make onChange handling like [event.target.name] = event.target.value. Like, if you have 20 fields need to be input and you dont want to make 20 useState/ useRef right? How can i do the same with useRef?
There is a use case for the functional approach to useState and it is when you have a specific need to update and then read/handle state value again within a singular event. It's a great technique, but it is not the only way and its existence does not make the other options wrong. I know it was just for example, but there was no problem with how the counter example was coded originally and it gained nothing by being refactored. The argument made in this video is like saying that its wrong to ride a road bike because a mountain bike is better at jumps. One is simply intended for navigating different types of terrain than the other.
Hey everyone, i'm learning react and i don't understand in the #2 tip where does "currentCount" gets its value from. Is it like, whenever you do an arrow function inside a setter, the argument passed to the fonction is the actual value of the state ?
Amazing tips, but I can't get my head around the last one. I don't understand how a second URL change, that initiates a new Abortcontroller, somehow cancels the first one. Perhaps I'm missing something on what the return function on the useEffect actually does, or when the return method is actually called?
Most valuable React tips I have learnt regarding some bad code practices I have been applying in React. Thanks for this very comprehensive video with lots of valuable information covered in just over 20mins.
1:35 false, you are using the email/pass vars in value={} because you have controlled input state. in real word scenario you might have realtime onChange/onBlur validation before submitting. so in the end you cant avoid having the state for each input. and if the app currently does not require the state (and you use refs), but it might need state in the future, then it[s still a good idea to use state from the beginning just to prevent major refactoring in the future.
Deeply amuses me that overuse of hooks has put us back into event driven callback hell. This is the exact code scattering that we were trying to avoid with functional components
@@georgethenewbie new toys don't solve talent problems. The symptoms described in this video are products of overloaded components. Move that code somewhere else and the semantics become clear. The functional paradigm can be very elegant but we have to put some effort in
You don't need an useEffect at 7:35, you could set the state and then do whatever you need to do using the amount variable, which is the value that the new state would get whenever it updates. So your code is actually a good example of an unnecesarry useeffect.
But his useEffect uses count variable, not amount? It's a good example on how to react to an update and I would say that useEffect is ok in this case. Example might really be basic, but it's ok that useEffect is used to react to a change in state.
@@rand0mtv660 Because count is a state variable, amount is not. But if he uses amount inside of the original function, he wouldn't need the useEffect in the first place.
@@rand0mtv660 there you can simply use regular setState(not functional), just precalculate needed value, set state, use precalculated value later in this handler, no need for useEffect, even beta react docs say that you often don't need useEffect
@@dagonzalez1757 ok but this is a contrived example to illustrate a point. Real world is usually way different and I would say useEffect is ok to illustrate a point here. I definitely do understand your point, but then again you maybe don't even need that state at all if you are just computing something and immediately using it for something else. There is potentially no reason to store it in state either.
Overall really good video so ofc there' a like from me but for the last issue the explanation was a bit too shalow and I didn't get it, maybe you coule extend on that in a separate vid with actual examples and more context? Anyway thanks for the knowledge sharing!
How come creating a new AbortController every time we call useEffect hook controls each individual fetch request at the same time, even thought controller every call of useEffect is a new object?
I'd like to see more use of spreading, `onChange(({ target: { value } }) => setName(value))`, and implicit return, `setCount((c) => c + amount)`. Get people used to seeing them and help them write cleaner code.
React's own docs explicitly recommend using state-controlled inputs over refs whenever possible. It refers to the ref method as "quick and dirty" because it lets the DOM handle tracking the value instead of React, which can sometimes cause unexpected behavior when React renders its virtual DOM. So... yeah. I think for forms, especially large ones, it's better to keep track of values in a single state object with key-value pairs. That does mean it'll re-render whenever a value changes, but since React only manipulates the DOM for the one input that's changed, it's not a big deal; and it allows React to have more control over, and more understanding of, the inputs, for optimizations.
The main issue with using local variables instead of useEffect for composite values is future-proofing: when you add more state to the component, those variables will be re-evaluated on every re-render even if they don't need to be. In such cases, I think useMemo is the optimal solution; in fact, it's why useMemo exists! (And I believe recomputing a memoized variable doesn't trigger a re-render the way setting state does, though I couldn't find anything definitive about that.) But you are right that in some cases, you don't need to listen for changes at all, since you can just use the new value at the same time as you're setting it on the state.
I think useRef should be used for forms, you don't want component re-rendering on every key stroke just for a form, but if you was using a search/filter input where you are filtering on the users key stroke then you would need to useState and make it a controlled component.
@@SahraClayton It only re-rendered the input DOM tho? Instead of the whole form if I understand it correctly. I don't think it's a big deal.
@@chonmon yes, not to mention you'll always want to have some kinda validation on the form.
@@chonmon it's not a big deal but if you can avoid any components from rerendering no matter how small is just a bonus. Also it's less syntax in that component, which looks nicer
@@SahraClayton then you can opt for other event like submit or blur to minimize re-render. Although useRef is a fine solution since there’s no re-render, using it with forms that have many fields or require validation will give you a hard time managing these fields’ value and their behaviors
A good thing to point out about the first mistake is that a good UX informs the user if the field has any errors while they are typing; in this case, this is not possible. Better to stick with states, but it is a nice thing to know.
well this is what I am looking for ages. THANKS KYLE, you made my day, now I can revise my old code at a higher level
The number of useEffect gotchas and permutations are just never ending. I have such a love hate relationship with this hook.
You and me both
I have a relation of pure hate with that hook
some of the senior developers in a company I worked for used to not approve my PRs asking for me to not use useRef to the store any state in react component. It is nice to see someone explaining why not every state needs to be rerendering the component on every data update.
For the first case you don’t need state or refs the onSubmit function has access to all the input fields via the event parameter
Thanks!
You're welcome!
Using refs instead of state does not seem right in this scenario. First of all, such a render does not create any overhead since behind the scenes react will do equivalent of what you have done with refs. Besides, these code will probably be improved with validators etc. which will result going back to state version
Sus lan
You're correct. React has always preferred controlled components (react handles input value) over uncontrolled components (DOM handles input value). This is second time I see Kyle making this counter-argument to use refs, which I think is incorrect.
This is really debatable, as the scenario Kyle mentioned is that, all the inputs are only used upon form submission. For experienced React developers, we have always been using controlled components and get really used to it, so we are very unlikely to use Kyle's uncontrolled ways in any circumstance.
@@ACMonemanband True. Refs are mentioned in the "Escape hatches" section in the new react docs, which for me intuitively tells that refs are used as secondary option when first option of controlled components doesn't work.
@@ACMonemanband These days I usually just use react-hook-form and don't worry if something is controlled or uncontrolled in a most forms. The fact is that for more complex forms that might compute a lot of stuff, uncontrolled form inputs are better because they won't re-render the whole form on each input change. If you need to do any active validation, you'll probably have to go for controlled forms because you'll have to react to form changes all the time and not just on submit, but in cases where you just need to validate on submit, you probably want to go for uncontrolled inputs.
Only reason I dislike his input ref example is because you'll rarely only work with two field forms in the real world and you'll most likely have multiple (more complex) forms in your app. At that point, just reach for something like react-hook-form and never worry about building forms in React.
Hey Kyle,
This is really very helpful for me.
Tomorrow I have a task to complete in my office.
I was worried about how to do that.
but, this video gave me a clear idea about that.
Thanks a lot. Keep going, bro.
Loves from Sri Lanka ❤
Thanks for all the react tips! Really helped me a lot :) will you ever put out a video of you playing guitar? haha
I'm pretty sure, that there is already a part in one of his videos, where he plays a solo... But I can't remember how it was called... 😄
This was a great video and helped me solve an issue i had with my hook, namely having multiple states update with an action needed once they were both updated. it took a while to wrap my brain around it, but this video really helped give me the vision. love your videos and that you go super in depth (in the longer ones). probably the best coding tutorials on youtube. if i ever get my web dev dream job, i will be getting you a few coffees/beers.
Man, using setCount( (count)=>{count + 1} ), it's the greatest way how to handle this real react problem! That's was extremely beneficial for me !!!!! Thank you!
Very clear video, I just switched to Typescript for last major project, took a bit of effort initially but rewards are great, the build step catches a good few errors very early. I think not using TS could be added to your list. I expect many that haven't given it sufficient time will disagree.
I spent hours on my degree final project sorting out errors that js didn't pick up until I tried to run a piece of code with an error in. Switched to TS and it's a million times better and Id also say I've learnt a lot more too
Just because 1 code logic doesn't align with your opinion, doesn't mean that you can term it as a "beginner mistake".
For handling form why not simply grab the input values from the onSubmit event? No need for state or refs.
Yes that is what I usually do.
const formData = new FormData(e.currentTarget)
and then
const [username, password] = [formData.get("username").toString(), formData.get("password").toString()];
looks cleaner to me than using refs or state there
well I still use state for input validation though
This is the single most useful video I've seen since I started React coding
Thank you for the great video! Regarding the choice between useRef and useState for form submission, I believe we should use useState instead of useRef. This is because we typically need to reset the input value to empty after submission. For input filtering, updating the state as the keystrokes change is necessary to display the latest value in the UI.
Hands down, what a perfect rhetoric - watched it with great pleasure - thanks
You really deserve thumbs up from me. Good Job. 👍
Many thanks! Good luck with your channel! Greetings from Kyiv!))
i love react and i love this youtube channel, hi from indonesia
Thanku Sir,
Your explanation is fantastic.
00:45 tag stores fields value
Fantastic! I’m just learning react and you’ve explained the funky behaviour I’ve been getting with useState perfectly. Thanks for taking the time to make these videos 😊
Why are you excited to watch while the other crying are u happy
one of the best React tips I ever learn on UA-cam. Thank you so much
15:45 in that case instead of useMemo we can directly use in the dependency array person.name and person.age and it will not cause rendering when you change the dark mode checkbox
if you want to use the AbortController, but you are fetching data in a function, instead of in a UseEffect. The way i do is, use a UseRef to save your AbortController, use controller.abort() in the beginning of the function , then create a new controller and assign it to ref.current. pass the new signal to the fetch and voilà.
Golden tips! Love content like that with different case scenarios and clear explanation! I have learnt so much! Thanks for sharing!
I've been tinkering with React here and there for about five years, this is the first I'm hearing of a functional version of useState.
You really have a talent for education my man. Whenever I'm not understanding something in web dev now I just search for web dev simplified and boom there's always a video on it. Thank you! These were really good tips for those of us just getting into front end :)
That last useFetch insight is very helpful! I think it could be even more so if combined with some king of debounce? So the fetch only runs after say 0.5s?
Interesting video Kyle! I noticed I do make a few of these mistakes myself. I think the problem is that us developers can be a bit "lazy" learning new frameworks. I understand how the useState and useEffect hooks work and I never took the time to learn about useRef and useMemo for example.
totally!
You'll use it once you handle big data and use expensive functions that can block the main thread
Well I this case the "lazy" one is the video author. Recommending using refs over state on 1.34M subscribers is a crime.
You just prevented some lay offs, great job.
if its a simple form then you can just take the values from the form event when you submit and you dont really need to keep state provided you have a vary basic use case for the form, complex validations and connected models then you'll probably go back to using state
best explanation of useMemo out here👏🏽
Good video. One tip: if the arrow function will return an object, you can just put the object inside parentheses instead of using a full code block with a return keyword. Example: () => ({ age, name })
Also I believe you can simply return controller.abort instead of returning an anonymous function which calls controller.abort()
Would you be able to explain to me what is being passed to currentCount at around 6:00? Does calling setState automatically pass in the current state as an argument? Not sure how else it would be possible since the parameter name seems to be arbitrary, ie prevState. It sounds like you know your stuff, any help would be appreciated!
@@billynitrus setState accepts a function which its parameter (currentCount) is the value of ‘count’ before being updated.
Ex. If count is 9 and you clicked on the ‘+’ button ,if you try to log ‘currentCount’ you would get 9 ,thus ‘return currentCount (9) + amount(1)’ will result in updating ‘count’ to 10
How do you empty the field of the form with useRef, after submitting. 2:55
How are you able to console log d at 11:40 but not console log count at 6:55 ?
I thought you said setting state happens asynchronously. Can someone explain the difference?
This was soo helpful. I had a beginner project, just for fun and I almost made all of the mistakes. I just fixed my code, and it looks much better now. Thank you
that useMemo trick... was lovely
It was worth to watch, I learned pretty valuable things especially the fetch abort, it's golden, thank you!
Soo good to see that there's finally more than just a guitar in your room :D just kidding, awesome video as always!
Great video! useRef seems neat, but you do lose the ability to have real time validation, as that logic would be placed in the onSubmit function.
Amazing! You make great content. I especially like your youtube shorts
6:50 - 8:20 is a golden tip for beginners
Last tip was really important ❤
When you have been working with react for years and you still learn from beginner mistakes video
I'm with ya
u r a genius ! I want to do a full course u offer , but I can't afford it.😢
I even express with words how much this video has helped me. I got answers to lot of my questions. Thanks Kyle💥
all good, but actually, 20:09 when you cancelling controller will throw AbortError so catch and finally functions will be run. I guess in that case we want check for AbortError and not set this error )
How do you deal with forms that are using dynamic data.. they are created dynmically. Is there a way to add each input add to a ref object or array of some kind for a similar effect? cant really add individual varaibles due to the way each element is added to the form.
First example is iffy advice for beginners. They won't be able to discern when they can get away with refs. It's better to use state by default because it's reactive. Going straight to refs is premature optimisation. What if your form has fields that should conditionally be shown depending on the value of other fields? You need to re-render. It's a pretty common case.
The first useEffect example is so spot on though. I see that all the time. And the referential equality problem is so subtle but so important to note! Nice work.
You are my hero.
Btw, I think that we all learned the hard way that adding the useState count twice in a row would still do it just once :P
This worked incredibly well! I can finally play it thanks
Hey, how come full names gets the updated value? Isn't state async and by the time it gets to the const full name we might not have the updated first and last name?
good explanation !!!, my problem can be solved, thank you very much..
this video is all react people need, thanks a lot.
You are wrong about using useRef for managing form values. It's even mentioned by one of the react developers at Facebook. You can even find this in the react beta docs. useRef is overly used by people who have used Vue js before. Well, react is different than Vue js
can you elaborate or reference the beta doc page about handling form values? what's the alternative then?
Awesome explanation ❤
Thank you so much, as a beginner you helped me a lot
Amazing explanation! Many thanks
if you are so sure that your url changes very quickly after another, I prefer using debounce instead rather than executing and canceling a fetch..
no request is faster than a cancel and re-request, canceling doesnt work if your API runs fast enough
In the first example when you simplify the input values with useRef() and onSubmit().. at that point .. could you not just destructure the values from the submit event itself? I wonder if theres another example that could work more effectively?
{} === {} false is the correct result for more than one reason but what I want to stress is that {} is NOT an object, it is the LITERAL CONSTRUCTOR hense don't tide the symbols to what they actually are, the constructors return objects.
Excellent video ty.
Excellent explanation on state setter usage
this is super helpful
which way is a better practice?
create components by:
export function Compoent() {};
or
export const Component = () => {};
?
export const Component = () => {};
This is the latest and also the better approach... 😉
1 question. So, when i do useState i can make onChange handling like [event.target.name] = event.target.value.
Like, if you have 20 fields need to be input and you dont want to make 20 useState/ useRef right?
How can i do the same with useRef?
There is a use case for the functional approach to useState and it is when you have a specific need to update and then read/handle state value again within a singular event. It's a great technique, but it is not the only way and its existence does not make the other options wrong. I know it was just for example, but there was no problem with how the counter example was coded originally and it gained nothing by being refactored. The argument made in this video is like saying that its wrong to ride a road bike because a mountain bike is better at jumps. One is simply intended for navigating different types of terrain than the other.
hmm I don't have this problem in angular xD but i'm trying to learn react this month. this is a good help
In case I want to clean up the input after submitting the form I must use state, right? or not?
Do we ne3ed to validate input fields on submit or for better ux when they type ? Whayt is right approach for production code ?
Hey everyone, i'm learning react and i don't understand in the #2 tip where does "currentCount" gets its value from. Is it like, whenever you do an arrow function inside a setter, the argument passed to the fonction is the actual value of the state ?
Great video. I don't know what more can i say. Cheers!
amazing video for react beginners. :) Thank you. Looking forward for more react mistakes that beginners and more advanced devs make
1. U don't need ref))) e.target.elements.email.value - is solution on vanilla javascript, but u need to set name attribute. it is direct value
How come the custom fetch hook is doing just (setData) and not data => setData(data)? Would that work?
Amazing tips, but I can't get my head around the last one. I don't understand how a second URL change, that initiates a new Abortcontroller, somehow cancels the first one. Perhaps I'm missing something on what the return function on the useEffect actually does, or when the return method is actually called?
i'm a react native developer and i commit some of this mistakes, thanks for this video
You are AMAZING ... Kyle 💐
For email/password you don't need refs, just grab values from the form. Yeah, inputs should have name attributes to be added
Most valuable React tips I have learnt regarding some bad code practices I have been applying in React. Thanks for this very comprehensive video with lots of valuable information covered in just over 20mins.
Nice tip last one.Thanks
Good work Kyle 😉
I really appreciate your explanations. Top-notch!.
last one just perfect! thanks!
Subbed for that beautiful Jackson guitar
1:35 false, you are using the email/pass vars in value={} because you have controlled input state. in real word scenario you might have realtime onChange/onBlur validation before submitting. so in the end you cant avoid having the state for each input. and if the app currently does not require the state (and you use refs), but it might need state in the future, then it[s still a good idea to use state from the beginning just to prevent major refactoring in the future.
Deeply amuses me that overuse of hooks has put us back into event driven callback hell. This is the exact code scattering that we were trying to avoid with functional components
this is why everyone's running away from React.
@@georgethenewbie new toys don't solve talent problems. The symptoms described in this video are products of overloaded components. Move that code somewhere else and the semantics become clear. The functional paradigm can be very elegant but we have to put some effort in
You don't need an useEffect at 7:35, you could set the state and then do whatever you need to do using the amount variable, which is the value that the new state would get whenever it updates.
So your code is actually a good example of an unnecesarry useeffect.
But his useEffect uses count variable, not amount? It's a good example on how to react to an update and I would say that useEffect is ok in this case. Example might really be basic, but it's ok that useEffect is used to react to a change in state.
@@rand0mtv660 Because count is a state variable, amount is not. But if he uses amount inside of the original function, he wouldn't need the useEffect in the first place.
@@rand0mtv660 there you can simply use regular setState(not functional), just precalculate needed value, set state, use precalculated value later in this handler, no need for useEffect, even beta react docs say that you often don't need useEffect
@@dagonzalez1757 ok but this is a contrived example to illustrate a point. Real world is usually way different and I would say useEffect is ok to illustrate a point here.
I definitely do understand your point, but then again you maybe don't even need that state at all if you are just computing something and immediately using it for something else. There is potentially no reason to store it in state either.
What if i want to change textinput value back to default value? Can i do this without using usestate? (Only with useref)
Why do you always prefer x => { return y; } over x => y 🤔? I don't get it
Nice video ✨
Overall really good video so ofc there' a like from me but for the last issue the explanation was a bit too shalow and I didn't get it, maybe you coule extend on that in a separate vid with actual examples and more context? Anyway thanks for the knowledge sharing!
best tips ever. i also was not using functional way of setting state
Thanks Kyle. Funny how I'm an advanced react developer and I make a couple of mistakes you pointed out.
this video is very very nice .
thanks Kyle
Great video ! Well explained ! Thank you, I'm modifying my code right now...
How come creating a new AbortController every time we call useEffect hook controls each individual fetch request at the same time, even thought controller every call of useEffect is a new object?
I'd like to see more use of spreading, `onChange(({ target: { value } }) => setName(value))`, and implicit return, `setCount((c) => c + amount)`. Get people used to seeing them and help them write cleaner code.
I really appreciate this video!! 🙌