Check out a free preview of the full Complete Intro to React, v9 course
The "Uncontrolled Forms Q&A" Lesson is part of the full, Complete Intro to React, v9 course featured in this preview video. Here's what you'd learn in this lesson:
Brian answers questions about use cases for controlled and uncontrolled forms.
Transcript from the "Uncontrolled Forms Q&A" Lesson
[00:00:00]
>> Male Student 1: I guess I just had a thought, I kind of answered it for myself here, but we put in those DevTools, we put in the React and the TanStack DevTools, and I was curious. My question to myself was, hey, can I inspect that call just there? And I absolutely can, but I'm wondering if, I guess maybe this is general for now or later, if there are any common uses you have of those DevTools, kind of think that we put them in there, and I haven't really touched them since.
[00:00:25]
>> Brian Holt: Yep, to get point here you can click the TanStack Query, DevTools down here, you see both quarries and mutation up here, you can see our query, mutation right there. This is just helpful for me to see, did it happen and what data got sent? That's 95% of my question.
[00:00:44]
The other thing I could definitely just look at the network tab right? And see what happened there but it's nice that it's here. I can see everything, what happened, what came back, how many things are subscribed to it, what kind of event triggered it? All that kind of stuff.
[00:01:03]
So do I need to see, is it cancelable all the time? No, probably not or probably never is probably closer to what I would say, but it's cool that it's there.
>> Male Student 2: When there are input validations, should we be using uncontrolled forms?
>> Brian Holt: Not necessarily it depends on how you wanna do it.
[00:01:24]
So, first of all, the browser already has some built into it. So if I just do this, it's gonna say, please enter an email address. That's from Firefox, right? That's not from anything. That's just from Firefox saying this isn't at least remotely approaching a valid email address. It's pretty loose, right?
[00:01:46]
So it will still allow some pretty weird things through. It probably will let that go, it did, right? And that's not about, obviously not a valid email address. But if you were trying to do a valid date of birth, right? And you wanna make sure that it's within the past 150 years, or something like that.
[00:02:06]
I still probably would do that on submit and why? It's a huge pet peeve of mine. If I started typing my birthday, which is 05 and then it turns red and it's enter a valid birthday. It's I'm not done yet. [LAUGH] Stop telling me that I don't have a valid, I'm working on it.
[00:02:27]
And so that's why I don't like using a controlled input because it would immediately show you that something is wrong, right? When in reality, you wanna show them at the end. It's no, actually, you have to be born within past 150 years for this to be valid, you would do that on submit, not on key down, right?
[00:02:48]
So still I would do uncontrolled for that and then just do it on the submit where I would do that.
>> Brian Holt: All right, there's probably other reasons as well.
>> Male Student 3: In my page, it has fields which has dependencies on other fields for instance, state and city. For that, should we use controlled forms?
[00:03:10]
>> Brian Holt: Yeah, that's a really good place to do it. So let's say you put zip code, right? And for example, in my old zip code in the Seattle, you could see this that you live in Seattle, or you could say you live in Greenwood, both are technically valid places.
[00:03:27]
And you would show that, probably in a drop down. And you would do that based on zip code which wouldn't be populated until they put their zip code in that you would use a controlled input for that.
>> Brian Holt: I'm not telling you do great, terrible things to avoid using controlled inputs.
[00:03:49]
But just mostly that they're not necessary for things of this nature, right? Where this is pretty extremely normal-looking form, right? And therefore, it's very valid to just not have to do anything controlled about it.
>> Brian Holt: Cool, again, we didn't hit any errors, but let's say that we hit a 500 or was it 437 I am a teapot error, right?
[00:04:22]
Something like that but inside of postContact, if this response was not okay, which is basically anything that's under 400, right? It would throw the error here. And then inside of contact, we would get a flag here from TanStack query and you could do something if, where's a mutation.iserror.
[00:04:56]
And you can see there's a bunch of them, is pending paused is idle, is success, blah, blah, but if error, you can just, return something again, very customer friendly, well, no, something like that, right? And that's how you'd handle errors in their posts, yeah Mark?
>> Mark: Is there a case where you use both uncontrolled forms, but a controlled input?
[00:05:23]
>> Brian Holt: Yeah, I mean, you can kind of see that I do that in order.
>> Brian Holt: So if you look here, we have this whole form. But I'm handling all of the data on submit, and then where am I taking that data? So this is setCard. So I guess I'm just doing this directly with the things that I have set in state.
[00:05:52]
But there's no reason that I couldn't have just done something like const formData= new form data, right? And done it the exact same way. Both are fine, at this point, you're kind of splitting hairs of what's controlled and what's uncontrolled, and really the answer is it doesn't really matter, right?
[00:06:12]
Just write the code that looks the best. But sure, yeah, you're gonna have things where some of the inputs will be controlled. Some of them will not be controlled, and you'll get it all off the form data that would make sense to me. It's not a binary thing, where either it's all controlled or all uncontrolled.
[00:06:32]
You can do both.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops