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.

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.

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

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

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 handling form why not simply grab the input values from the onSubmit event? No need for state or refs.

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.

The number of useEffect gotchas and permutations are just never ending. I have such a love hate relationship with this hook.

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 ❤

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

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()

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 😊

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.

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!

Pretty great tips for React! However, I have a couple of disagreements with your mistakes. Maybe I'm wrong, but I'd be curious to discuss with others here: 1- useRef vs useState for forms: Using state to update and rerender form inputs is what a controlled form is. If you use useRef you can't apply conditions or mutations on the inputs, you'll trust your DOM into having the right information instead of your state. So even if it works, if you need a form, use a state, not a ref. 2- prev vs count: I disagree with using prev everywhere, especially with the example that you're using. When I use count, I know what count is, all the time. if I use prev, I need to look through my entire code between the state and my function to 'count' how many times did I call setCount. Also, you should do all the work, then call a setState, not do a setState party in my opinion. Continue the great work!

{} === {} 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.

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

Golden tips! Love content like that with different case scenarios and clear explanation! I have learnt so much! Thanks for sharing!

It was worth to watch, I learned pretty valuable things especially the fetch abort, it's golden, thank you!

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à.

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

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

00:45 tag stores fields value

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.

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 :)

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

Amazing! You make great content. I especially like your youtube shorts

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.

one of the best React tips I ever learn on KZfaq. Thank you so much

This is the single most useful video I've seen since I started React coding

In the last example, @WebDevSimplified are you sure the aborting would "ignore" the `then`, `catch` and `finally`? I am pretty sure aborting this way would still fire `catch` with `error` being `DOMException: user aborted the request.` and `finally` setting the `loading` to `false`, or wouldn't it?

For email/password you don't need refs, just grab values from the form. Yeah, inputs should have name attributes to be added

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

amazing video for react beginners. :) Thank you. Looking forward for more react mistakes that beginners and more advanced devs make

that useMemo trick... was lovely

This worked incredibly well! I can finally play it thanks

Thanks for all the react tips! Really helped me a lot :) will you ever put out a video of you playing guitar? haha

You really deserve thumbs up from me. Good Job. 👍

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.

Nice tip last one.Thanks

Well, like others in the comments have pointed out, useRef over useState shouldn’t be taken as a general rule. Aamof, for the example discussed in the video, it might be best to leave the inputs as uncontrolled components if their values are not explicitly used. The FormData API can be conveniently used in the submit event handler to get access to actual values at time of submit. That said in non trivial examples it’d typically not be the case as you’d want client side error handling and what not. Just use useState then. Also regarding the last suggestion in the video, the behaviour described for AbortController is not accurate. Aborting a request using AbortController doesn’t prevent the promise returned from fetch() call from settling. The promise will actually be rejected with DOMException having code ‘AbortError’. While cancelling previous requests in this manner you’d want to explicitly ignore these errors (and not display them to users as error). An alternate method I have used to solve the same problem is to keep track of start time of the current request (via closure), and start time of most recent finished request (via ref). When a response arrives, check it’s start time against most recently finished request’s start time, if it’s not later just ignore the response. Sounds complicated but can easily be wrapped in a small lib function.

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

this video is all react people need, thanks a lot.

IIRC, setState is not asynchronous. The reason the "count" variable is not updated is because it doesn't directly reference the actual state. "count" references a copy of whatever was in the state when useState was called. Other than that, this was a great video! I still catch myself forgetting to use the function version of useState, so hopefully I'll remember this video the next time I do! (Edit) see the comments for more details!

i love react and i love this youtube channel, hi from indonesia

Thank you Kyle!

Everything is so clunky in React... Unfortunately I have to work with it, but vue is on another level.

The first case. Is just simplier and better to put names on the inputs. Then when submiting, get all inputs inside the form and reduce them into a single object. const inputs = Array.from(target.getElementsByTagName('input')) const values = inputs.reduce((a,{name, value,...rest}: HTMLInputElement) => ((value && name) ? {...(a as object), [name]: rest.hasOwnProperty('checked') ? rest.checked : value} : a),{}) onSubmit(values, event.target). What this cause is that you could wrap it into a 'Form' component and re use it every time you need it. And its dynamic, if you add an input to the form with a given name, the value of that input will be in the values object. No need to repeat yourself with each field

Thank you so much, as a beginner you helped me a lot

You would still control re-renders by using denounce on top of state. So, there won't be a need for ref in this case. As the react doc itself suggests us to go with controlled components over uncontrolled components Useful video thank you

Don't even need the refs if you serialize the form data on submit using `const formData = new FormData(e.target);` and `const formProps = Object.fromEntries(formData);` Just make sure to give all your fields a name attribute and you're good.

Excellent explanation on state setter usage

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?

You just prevented some lay offs, great job.

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.

last one just perfect! thanks!

All good, thanks, but it's really wierd to see that you don't use semicolons - it's a direct way to have errors.

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.

best explanation of useMemo out here👏🏽

Last tip was really important ❤

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.

hmm I don't have this problem in angular xD but i'm trying to learn react this month. this is a good help

It does work as the same as before in case of email and password, but we use usestate , value and onchange to create Controlled components. Uncontrolled components with refs are fine if your form is incredibly simple regarding UI feedback. However, controlled input fields are the way to go if you need more features in your forms.

Great video ! Well explained ! Thank you, I'm modifying my code right now...

This is the first time ever I comment on a KZfaq video but I think I should for the first time. I’ve been using React for the past 5 years and the “mistakes” shown in these video are no mistakes at all. They are perfectly valid and in my opinion preferred because it has a more pragmatic syntax. Yes, the alternatives can be considered (not in all cases) more efficient but these are not mistakes.

For the first example, you don't even need refs, you can capture the input values on the form submit event if you give the inputs a name attribute. const data = new FormData(event.currentTarget) keys will be the input names

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

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

which way is a better practice? create components by: export function Compoent() {}; or export const Component = () => {}; ?

Thanks. I didn't knew these.

you don't need id just wrap your input with your label use name on the input component {`Email`} you don't even need ref you can take all the form values from the form submit event const form = e.target; form.elements['name'].value

Thanks a lot. These are very important and useful knowledges.

this is super helpful

Actually, You don’t need a Ref also, what you need is a unique name for every input then use form data. let formData: FormData; formData = new FormData(e.target); const formProps = Object.fromEntries(formData); all the inputs will be converted to objects.

u r a genius ! I want to do a full course u offer , but I can't afford it.😢

6:50 - 8:20 is a golden tip for beginners

Soo good to see that there's finally more than just a guitar in your room :D just kidding, awesome video as always!

Excellent video, thank you very much.😊

Common React Hook mistakes, so clearly explained. Thanks, Kyle {2022-10-16}, {2022-11-01}

Really useful one. Please keep on making great informative videos like this. You're the best!

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

thank you for this great quality content

I'll be honest, I started this video thinking I wouldn't learn anything and I did learn a couple of things! It's bit slower pace than I'd like but I'm sure the format is perfect for wider audience. Thanks for making it, and thanks for this content, much appreciated!

I really appreciate your explanations. Top-notch!.

yes, beautiful nerds do exist. anyway, you're actually one of the top 5 (quickly becoming top 2) i've found on this site for react stuff, and i'm expecting it's the same elsewhere. nice work buddy.

16:16 Instead of using useMemo in this scenario can we just put those two objects of name and age in the useEffect's dependency

Many thanks! Good luck with your channel! Greetings from Kyiv!))

Great video. I don't know what more can i say. Cheers!

best tips ever. i also was not using functional way of setting state

Adding on what's people saying about point #1; if you use useRef instead of useState while using Typescript would complicate things while asinging the proper types making it more easy and clean to just use useState

The last one did not know... Thanks buddy...

i'm a react native developer and i commit some of this mistakes, thanks for this video

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?

I had a question about aborting a request in final exam. Though my teacher had explained me the necessary of canceling the request when component unmounts I understood vaguely. It's clear now thanks for your well explanation about the last mistake

Subbed for that beautiful Jackson guitar

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!

This was really straight to the point and very helpful. Thank you Kyle! :)

You are AMAZING ... Kyle 💐