Why I avoid react's uncontrolled inputs 

You are 100% correct. I've had this conversation many times. It's annoying. It's like watching developers implement Redux to manage a couple of bits of state.

These videos where you give common use cases for all of these problems are insanely valuable and make it much easier to understand. Keep it up man.

One of the most important lessons is don't prematurely optimise your code. This relates both to performance and over-generalising code for the future

Great video. When I first started with React and discovered that the whole page re-rendered when I updated a form input, I started obsessing over limiting the re-renders - I even ended up building a pub/sub state manager to limit it. Then it dawned on me that the re-renders are so fast and heavily optimised under the hood already that it's really not a problem. I would cry if I saw that uncontrolled input app you created here in a production system that I needed to maintain, the controlled inputs are so much easier to work with.

I'm not an "avoid all rerenders" fundamentalist, but I think I know why people told you in the last video not to use controlled inputs. There is a case when you have a select input that you are populating it with that comes from something like: {options.map(o => } In this particular case, for every key stroke you do, this map will have to rerender all the options again, and again, and again... If you have 3 options, this could be imperceptible, but let's say you have 30 or 40 options (a countries select for example), every key stroke will have to rerender all the form and 40 options needlessly. Now let's suppose you have more than one select, and it's not a plain html select input, but it is some fancy select with styles and other things... That could be pretty bad for the performance, and it's actually perceptible. You can do this test: grab your phone, and write "hello world" in an input, then, hold pressed the "delete" button, and you will see that the app will get unresponsive for a few moments while it's deleting the text. And that's because is rerendering multiples selects with lots of options. It had to delete and re render 440 options elements. I know this is a very particular case, but this kind of situations made me realize that it is important only to grab the form data on submit event, and not before. This is not a "good practice" it's just a good approach for a very particular case . Lastly, I would say that you are assuming that everything will perform perfectly because you are running that app on your Mac. At least in other countries (my particular case is latin america), assuming that all users will have an iphone is very bad. That's why that "it's an imperceptible 4ms rerender" could become much worse in some cases. Sorry for the text wall, I'm not teaching nothing to anyone, I just wanted to share a different point of view and to say that this thing about "uncontrolled forms" is something that is good in some cases, but I agree that maybe having the most readable code is gonna win unless performance is critically important

the only time I've used the uncontrolled way, is when I implemented monaco editor as a field in my form. and they have this method called `onMount()`. where it gives you a function which you'd use to get the value of the editor whenever you think it's time normally before the form is being submitted. so most of the time as the guy who wrote the docs said... your form is just fine with the controlled way. thanks for the cool vids. keep it up.

If render speed is concern (can happen with large forms) you can still go with state based approach, wrap the form elements in custom component and apply React.memo to the custom component.

Great explanation!, I kind of understand where those comments are coming from. I used to blame re-rendering all the time, and it turned out the bug was somewhere else. I’d suggest to those guys to check if they are making the same mistake I was doing of writing functional components inside the parent functional component. That messes everything and makes you believe the rerendering is the problem, but it’s not, just replacing those to the top of the file (outside the parent functional component function) will fix most of the issues.

This is a very common use case which we normally don't pay much attention to. Thanks for clearing this up .

Well said, good sir. Thanks for talking about the nuance about the speed of renders vs. the maintainability of the code. I was recently told that another reason for trying to "optimize" or "eliminate" rerenders is in the case where a child component has some side effect (like an API call or some sort of low-level DOM manipulation) that you don't want to happen each time the parent is rerendered. In my case, we were using Ant Design to build out a UI, so the child component wasn't specifically authored by anyone in my team. So, I was advised to use the useMemo hook when passing an array as a child component prop so that the child didn't rerender as a result of the reference to the array changing. Do you have any thoughts about this argument...namely, eliminate rerenders when child components may have side effects that you may not want to run?

Your channel is really helpful.. keep on posting

I always use Formik+Yup for forms, it renders everything when an input changes which is ok, it's soo good for error handling and input types.

Very very nice video, thank you so much. Just curious can you please tell or better yet make a video on a real life scenario where uncontrolled forms might be a better option.

The other thing is that the rerendering is optimized in such a way that it takes place on the elements that change, not the whole component is rerendered. The whole component is checked but not built from scrach on every change. Therefore the extra code and functions from refs might slow it down too

Thank you for nice explanation. How can i see video from the begging of current video?

Great video, especially that you should considering code maintenance before pre optimalisation. However consider using react-hook-form since it provides far more things than just form state, like only showing errors on submit, dirty state, auto focus on errors (after submit), validation abstraction and more to provide a better UX for end user.

Great job.

In your example, you are correct. However, a lot of people using some sort of a react ui library. If you adjust your code to use mui TextFields wrapped by an mui Grid, the site becomes slow even with 10 rendered inputs. We could argue that using ui libraries such as mui is not a good idea in the first place, but it is a good example for when you would want to use uncontrolled inputs even with a small amount of inputs.

I feel this example isn’t doing the uncontrolled components any justice by only replacing controlled components with manual JS. There is built-in form validation in the browser. By adding `required` to the input fields and adding CSS `input:invalid { border: 1px red solid; } input:invalid + div { display: block }`. But if you need the heavy lifting of custom validation, yes, use controlled components. The browser has a lot of these things built-in if you know what to look for.

Hi Cody, another question off the topic, I am wondering how you gonna type the form object, give it like 30 pairs?

i think i like using the react-hook-form library, it takes care of the re-renders & error-handlingd. That being said, i'd pick controlled inputs over refs. Ref is just like manipulating the dom directly, that's a bad practice for forms, that's not what refs were meant for

tip not very related with the video: const handleSubmit = (e) => { e.preventDefault(); const data = Object.fromEntries(new FormData(e.target)); } that gets all the values in an object of the inputs that are in a form and have a name attribute, is very easy to use and its uncontrolled, I like to use it with vanilla js

Hey I really like your videos :D I have been trying to figure out the best way to make a form for like a week. I think this is a contentious question because there are so many ways to do it. However, I'd like to make the case for useRef one last time. If you need to make a form with a submit button, you don't need to do all of this instantaneous error checking in place. When you press submit you can check if the DOM nodes exist (by checking the Refs are not null). This allows you to use semantic html and guarantee that the nodes are present when you press submit. import { useRef } from 'react'; export default function Form() { const textInput = useRef(null) const phoneInput = useRef(null) const emailInput = useRef(null) function handleSubmit(e) { e.preventDefault() if (textInput.current && phoneInput.current && emailInput.current) { const submitObj = {} submitObj.text = textInput.current.value; submitObj.phone = phoneInput.current.value; submitObj.email = emailInput.current.value; console.log(submitObj); } } return ( handleSubmit(e)}> name phone Format: 123-456-7890 email ) } If you want to do error handling and stuff on the fly then I think controlled components are a much better use case, but I don't really see the problem with refs as long as you guarentee the nodes are on the page. Let me know what you think, love your stuff! edited: for the if statement it should be .current, I updated it.

Thanks for the demo. I just duplicated your code locally. I found that the form renders immediately every time I type a single letter in the input. Then I have to use mouse the focus back to the place I just wrote the letter, then it re-render again. I need to re-focus again and again in order to write a word. How do I fix this. Btw, const keys = Object.keys(initialFormData) is pretty neat. Solution: I am thinking usually no such thing will happen if I use e.preventDefault() inside onSubmit. This video is for the demonstration of re-rendering, the question above is really irrelevant, sorry for that.

What about the case when a change in an input triggers a big change in the parent or sibling component?

If you somehow got to a point where you are worrying about re-renders it's probably better to use memo to only re-render what is updated.

Amazing, can't agree more 💯 These people are really annoying who run after saving a few ms and nanoseconds. They are still living in 80s and 90s. Optimize only when needed and you have run and tested both the solutions.

While I agree that rerenders "can be an after thought, given the speed of rerender's". For the devs that are used to answering the interview questions and are always optimizing to get things to O(1) I am sure the additional rerenders are like nails on a chalkboard. Its also probably a good habit to get used to avoiding rerenders if you can, because at some point your likely to transition to Next.js for some project. And rerenders do matter here, especially with server side components.

Re-rendering is so fast that the user hasn't let go of the right mouse button by the time it's complete.

U have app for customer that can control multiple shops,shops have working hours and lets say some have 24/7.U need to control that by inputs. Now some calculations customer have around 200 shops and they all need to be listed in one component and thats 4800 inputs and can say thats average customer. Now u have 24 master inputs for every hour that can copy values to every hour sites if u get lucky that customer wants something universal for shops for that pratucular day soo u need only to put values once and they apply to all sites and u can do that in 24 inputs its 15 sec work. Now some of that sites sometimes want different values so inputs must stay there... Just did some test and try with controlled inputs on test customer with only 2 sites its around 120ms with ofc 24 rerenders and can its bad situation. Soo point is that there are use case when u cannot use controlled if u have like specific app.but ofc for user forms like name,address etc its fine.

React Hook Form used to do uncontrolled inputs in the past, but now they use controlled inputs from v6 and minimize the re-renders. Not sure though!😕

interesting 👍

The uncontrolled components use case has to do with prop drilling handlers and trying to update state on possibly unmounted components.

A lot of these misconceptions come from Web Dev Simplified viewers.. He recently made a video about how you supposed to be using uncontrolled inputs for forms.

Good points, and I'm not sure where the "controlled components are bad practice"-advice (which directly contradicts the docs) comes from, but I think it might be from a Web Dev Simplified video. No shade towards the guy, but he sometimes makes videos that go against the advice of the docs without justifying those choices or even referring to the docs which makes me think he might simply not read them. Other than that I know his videos help a lot of people, but IMO that approach to making content is irresponsible, which is why I'm glad you referred to the docs and used the profiler.

Sometimes I like using uncontrolled components, but if it comes down to readability, maintainability, etc I would definitely use controlled.

Good points, but uncontrolled doesn't mean you can't set styles based on state. You could even set the defaultValue, and it still would be an uncontrolled input. Uncontrolled means no onChange, and not setting value based on state, that's all

I always cringe when people tell me i should swap Formik for React Hook Form because Formik is slow/controlled. Never had issues with Formik performance on production (it sometimes runs slow on dev, but only in dev), and I did some big multipage forms using a single useFormik and tested them on old android phones and they worked fine.

You are right, please do more performance explaining videos.

Use classes instead of cluttered style manipulation? With all different ways to solve form handling it seems to be a good idea to have a global solution or perspective for forms. Has it happened before that it feels at least great on my high-end dev computer? ;-)

You’re showing a very bad example for uncontrolled inputs. There is at least one use case for uncontrolled inputs and it was the one for your beginner react challenge. If you don’t need to do onChange input validation and just need a ref to the value, uncontrolled inputs are okay.

noticed you watch andrew tate on youtbe good work!

just use signals

Basically a soft skills problem. People are like: "Hey, actually is a bad practice if you don't do things the way I do", like, fuck documentation and context of application.

Good job babe!!!!

Lol they gave horriable idea. Might as well go back to jquery at that point.

Uncontrolled inputs make no sense due to amount of boilerplate and vanila js, why bothering yourself with that if you are already using react :D

And have you guys tried covering your form with Jest unit test for submit event? For, like, an uncontrolled form that collects user inputs by addressing form.[name].value inside onSumbit? Go give it a try. Pure Node env, as it turns out, doesn't respect this at all. The pain I'm here because of, and currently trying to solve without changing our forms to controlled. Wish me good luck lol.