In the last section we did a little refactor on our search for our component in this video on it tell
you a little bit about what's going on with the code inside of here.
And then I'm going to tell you exactly what the differences between a uncontrolled and controlled component.
So first what is going on with that code is the way to explain this would be to show you a flow diagram
of what is now happening inside of our component.
And then for each step inside of your we'll go back and refer to one of the different lines of code
that we have.
So first thing that happens is the user types in that input and the instant they do our callback gets
invoked.
The one that we are passing to onchange right here.
So the instant a user types that input this function gets called just as we were talking about a couple
of videos ago.
Then inside that callback we pull the current value of the input or the whatever the user just typed
in there out of the event object and we update our state on our component by calling set state.
So right here inside the body the callback we take that event object which we are abbreviating simply
as we pull the change in that input.
How did that event object by referencing event target value.
And then we update the state on our component with that new value.
So now this state term is going to contain whatever the user just typed into that input.
Now here's the important part.
Remember any time we call set state the component is going to automatically render itself so the render
method right here gets called a second time the instant the user type something in there.
And now here's the critical part.
When the component renders we take the value of that input or we take our this state DOT term right
here and we assign it to the value prop of the input the value prop right there is going to essentially
overwrite whatever text is already inside of the input.
Now I can demonstrate that to you very easily.
Notice how I'm gonna change this line right here.
I'll change it to something like that.
And now if I flip back over you'll see that my text input right here now has all that jibberish I typed
in.
So whatever we assign to that value prop is what the input is going to show.
So the net result of saying the value is this not states term is we take whatever string is inside of
this odd that term and we essentially push it into or we shove it into the input.
All right.
So this entire series of changes or this entire flow right here is what constitutes a controlled element
with the factor we just did.
We now have a controlled element because we are now going through those steps before we were not going
through those steps.
And we had a uncontrolled element.
Now let's talk about exactly what the difference between the two is and why we prefer controlled elements.
All right.
So another quick diagram here.
Now this is a diagram of the code we had before we just did that refactor.
So like the code we had like two videos ago before we refactored it to be a controlled component.
So let's consider the side Grahm with the older version the code on the left hand side I've got a diagram
of what we call the re-act world.
This is essentially all of our javascript code all of our components all of our classes all that stuff
and then on the right hand side is the T.M. world.
And this is essentially all of the HTL that is showing up inside of application and displaying some
information to the user.
Now with the old version of our code what would you say or how would you answer if I asked you What's
the value of the input.
Like right now I want to say right now I mean like basically at any instant in time well with the older
version of our code the only way that we could somehow figure out what the value of our input was at
any instant in time was to reach into the DOM find that input element and pull the value out of it.
That was the only way that we could answer that question.
We had to reach into the DOM and pull out the value.
There was technically a time when our Riak component or our area code understood what the value of the
input was.
But that was only during the time that a user had actually typed something into the input and we had
our callback vote so only during that very small that very slim period of time when our clock was running.
Did the Riak component have any idea whatsoever what the value of the input was during all other periods
in time.
The source of truth so to speak or the source of data inside of our application was inside of our HTL
document and it was not inside our component.
And that's the key part to understand.
You and I as developers we do not like to store information inside of our HTL elements.
In the case that we had before before we refactored it over to be controlled the input tag itself was
storing the value.
It was the only thing inside of our entire application that knew what the value of the input was.
And we don't like to do that.
Instead we want to centralize all of the information that we have inside of our Riak component.
That's what we want to strive towards.
We want to make sure that they react side of our application.
It is what is driving all of the data that is flowing through our app and we're not going to somehow
store data inside the DOM.
So let's look at the same diagram but after we refactored it to be controlled OK.
So here's what is happening now.
So now if I ask you exactly what the value of the input is at any instant in time you don't have to
go over to the DOM.
You don't have to look at the DOM.
You don't have to somehow reference that input and pull the value out of it.
Instead we can look directly at our component.
We can look at it state object and see oh ok my component has a term of high there.
That means that the value of my input must be high there.
And we were able to answer this question without having to try to dive into the to that Dom.
In fact if we try to go into the DOM and we looked at that input we would more or less be just troll
like hey like go look at the state to get the current value.
I don't know what it is at this point.
We will not go into the DOM or find the input to find out what the current value is we're going to always
just make use of our Riak component I guess that's the difference between a controlled and uncontrolled
component.
The key idea here is that we are storing our information inside of our components on our state property
as opposed to storing information inside the dorm.
That's the key thing to understand.
Now the challenging part about this the part that seems really confusing in my opinion.
Maybe you disagree with me maybe it's crystal clear.
But I feel as though for a lot of people the hard thing to accept to your is that when the user types
in the input the input knows what the text is you know the input contains that text.
We then call on change right here and we inform our component like essentially after the fact of hey
here's what the new text is in the input.
And then when we read render the component we set the value on the input with essentially the value
that is already in there.
Remember the input.
It knows what is being typed in there.
But we're kind of like overwriting that and it's sticking to a new value back in and it's the same value
that was already in there.
So that's the part that I think for a lot of people is hard to kind of understand or accept we're kind
of like doing more work than is necessary here.
But again the entire idea is just to make sure that it's the re-act application driving and storing
all of our data and not the HGL side of things.
Now even when I tell you this you might say OK like sure we want react to dry everything and we want
to store information in components rather than in the door.
But you know what.
I don't care about that.
I've worked with other applications before where we store information in the dorm and everything works
out just fine.
Maybe you fall in that category.
Well OK I accept that there are other frameworks out there other javascript frameworks that store information
in the DOM and they do just fine.
But all I can tell you is this is how we do things in the re-act world.
The good thing about this approach is that it makes doing certain steps pretty easy and pretty straightforward.
For example if I wanted to render my search bar with some default value inside the input I can very
easily change the initialization of the state term right here to say like say hi there so now when my
component first renders the input will be rendered with a value of.
Hi there.
So now if I flip back over we'll see that every time that my input first renders I see the text.
Hi there inside there by default.
And I of course I can change it if I want to.
And then every time I refresh it I'll just default back to hi there.
So that's kind of easy to do.
You know it could very easily default the value of our search input.
The other thing we can very easily do is manipulate the whatever the user is typing in there for every
single key press that they enter.
So for example let's say that we want to force this text input to always have capitalized values inside
of it no matter what the user types.
So we don't want to let the user to put in lowercase characters we always want to see uppercase like
so to do that we would find right here where we get the callback for on change and we would say that
we would take the user's value whatever they just typed in and we would just say to upper case we're
going to take that value we're going to force it to be upper case.
Then revenger the entire component render the input right here and force in a capitalized version of
the value to it so I'll save this.
And now when I type in here I don't have my caps lock key on or anything like that.
I am forced to enter capitalized keys so certain operations get really really easy when you start using
controlled components doing something like this right.
You're forcing couples input would be not impossible to do with traditional HTL events like a traditional
event listener on the input right.
It's not impossible by any means but it would just be a little bit more challenging than it by using
a controlled component as we are over here.
OK.
So I think we've spoken enough about controlled inputs.
This is a topic that we're going to revisit many times throughout this course because it's not only
for text inputs it's for many other type of elements like say a select option or radio buttons or checkboxes.
All these different type of form inputs are all going to fall underneath this kind of controlled verse.
Uncontrolled topic.
So you'll get a lot of experience with this over time.
All right.
So lesing going to do here is remove the two upper case and I'll save.
And now we're back to how we were before we could put in lowercase characters.
OK.
So 6 good.
Let's take a pause right here and we'll continue in the next video.