All language subtitles for 007 Working with _ref_s_en

Now, with fragments and portals,

we had two cool features

that help us write cleaner HTML code.

The app worked in exactly the same way

before we added those features too

but with those features,

we end up with semantically more correct HTML code

and that's never a bad thing.

It makes your app more accessible,

makes sure you don't render unnecessarily many divs

and in general, shows that you are a developer

who knows what he's doing.

Now let me move on to one last key feature,

which I also wanna show you,

which does something different

than fragments and portals though.

And that would be refs.

References but the name in React is just ref,

so the short form of reference.

What do refs do?

Refs are actually quite powerful

as we will see throughout the course

but in their most basic form,

they allow us to get access to other DOM elements

and work with them.

Now, what do I mean with that?

Let's go to the AddUser component again.

There we have our inputs

and we manage what the user enters

by simply keeping track of it.

We simply have our state

and with every keystroke,

we update our state.

So with every keystroke, we update the value we get

by the user and we store it in our state

and we feed that state back into the input

and we then use that state later on

to reset the inputs but also to send it

to the place where we need the data.

So that is a perfectly fine way of managing this.

But updating the state with every keystroke

when we only need it when we submit the form

sounds a bit redundant to me.

And that's a scenario where refs could help us,

though they're not limited to that.

I will already say that.

How do refs work?

With refs, we can set up a connection

between a HTML element which is being rendered in the end

and our other JavaScript code.

And for that, we first of all, need to create a ref,

which we do with the help of another React hook.

We use the useRef hook here

and we then simply call useRef here in our code,

in our functional component.

And like all React hooks, useRef is only usable

inside of functional components.

Now, what does useRef return

and which value does it take?

It takes a default value you wanna initialize it to

but we don't need this here

but I'm very interested in what it returns

because it returns a value

which allows us to work with that ref later,

so which allows us to work with that element

to which we're going to connect it.

And therefore, here I'll name this nameInputRef

because I plan on connecting this ref

with that first input,

which allows us to enter a username.

So here we have the nameInputRef.

Now I'll duplicate this and create another ref

by calling useRef again

and that will be my ageInputRef.

So now I've got two refs

and they're just sitting there doing nothing.

They're initialized to be undefined

because that's the default

and they're useless.

Now, we can let React know

that we wanna connect a ref

to a HTML element by going to that element

to which we wanna connect the ref

and adding a special prop there, the ref prop.

Just like the key prop, that's a built-in prop,

which you can add to any HTML element

because, and that's important,

you can connect any HTML element to one of your references.

You will very often do that for inputs

because you wanna fetch input data, for example,

but you can do with any element.

So here I've got my ref

and now I will pass nameInputRef as a value here.

And nameInputRef is just that constant,

which stores this first ref.

So with that, I'm connecting this ref,

which I created in this component

with that JSX code that is rendered

by that same component.

And now a connection will be established.

The first time React reaches this code

and renders this code,

it will actually set the values stored

in nameInputRef to the native DOM element

that is rendered based on this input.

And that's important.

What will end up inside of nameInputRef in the end

will really be a real DOM element later.

So let's do the same for the age

and here I'll connect this to ageInputRef

and that's now connected as well.

So now the refs are connected.

What's the benefit?

Let's go to our addUserHandler function

and after event.preventDefault,

I wanna console.log my refs.

Let's start with the nameInputRef.

If I log this here and I go back

and I go to the console

so that I can see the log,

if I submit this,

you see there's an object being output here.

There is a object being output here

and that object has a current property.

Now, that's important.

This ref value, which is being generated here

always is an object,

which always has a current prop

and the current prop holds the actual value

that ref is connected with.

Now, by default, it's undefined

but as soon as this code ran,

because of this ref prop,

the nameInputRef is connected to that input

and hence, it's actually the input

which is being stored as a value in the current prop.

And what's being stored here really

is the actual DOM node.

So not some theoretical value or anything like that

but the real DOM node,

which you could now manipulate

and do all kinds of things with.

Now, it is recommended that you don't manipulate it.

Your DOM should really only be manipulated by React.

You're using React to let it do all the heavy lifting

but reading data from the input doesn't sound too bad

because you're not changing anything with that.

You're just reading data.

So here instead of logging this here,

we can, of course, read current.value.

Now, current refers to the value stored

and the value stored is the input element

and every input element has a value property in JavaScript.

We can actually see this here.

There's the value property.

So if I now save this

and I log this value, if I enter Max here,

you see MAX being logged here.

And that's pretty cool

because that means we can get access

to the values stored in the element

without having to log every keystroke.

We don't need state for this.

We can just read it when the submit button is pressed.

So that means we could now replace console.log

maybe with a helper constant,

which we use inside of addUserHandler.

I'll name that constant enteredName

and simply store my current.value in that.

And I do the same for the age.

I add my enteredAge and store ageInputRef.current.value.

Now, enteredAge clashes with my state here,

so therefore, I'll pick a slightly different name,

I'll use enteredUserAge here.

Now we can check enteredName here

and enteredUserAge here

and also enteredUserAge here in this condition.

So always the values we retrieved from the refs.

And I also use enteredName here

and enteredUserAge to submit it to onAddUser.

Now, with that, of course,

we should no longer reset these inputs

by resetting the state here though

because we're not using the state

to get our values anymore.

We currently still have those listeners

but we actually now don't really need those values anymore.

We're using refs to get the values.

So what we could do

is we could get rid of these states here.

So of these states where we listen to every keystroke.

Therefore, get rid of these state updating functions

and get rid of these two handlers.

And also, get rid of the value property

and the onChange property on the inputs.

With that, we shortened that code quite a bit

and we're relying on refs to read the values.

Hence if I add Max, 31,

you see we still can add that user.

However, during the process,

we lost our resetting logic.

Now, to bring it back, we've got two options.

We can switch back to the state-based solution,

which is not bad but I wanna show refs here.

Or we do something which you should rarely do

but which actually is okay here

in the context of a input field value

which you wanna reset.

You can manipulate the DOM without React

and yes, I said you shouldn't do that

and you typically shouldn't do that

but if you just wanna reset the value entered by a user,

it is something you can consider doing.

So we could use the nameInputRef.current.value

and now set it to an empty string

and repeat this for the ageInputRef.

And with these two lines added here,

if we now check this again,

you see now it's cleared.

Again, rarely do that.

Rarely use refs to manipulate the DOM.

Here we're not really manipulating the DOM,

we're not adding a new element

or changing a CSS class,

I'm just changing what the user entered.

You could argue that you don't even wanna do that

and in that case, you can always return back

to the state-based solution

but I think it's fine.

Now, in general, the question is not whether refs

or state is better.

You can use either of the two.

You will sometimes have use cases

where you just want to quickly read a value, for example.

And if you only want to read a value

and you never plan on changing anything,

well, then you don't really need state

because just to use state as a keylogger

is not that great.

It's a lot of unnecessary code and work.

So if you just want to read a value,

refs are probably better.

In scenarios like this, it's up to you what you prefer.

Refs, which are a little bit less code

but you have this edge case of manipulating the DOM,

or a state, which is definitely cleaner

but is a bit more code.

It's up to you but we will see refs throughout this course

and you will see them in a lot of projects,

in a lot of React projects

because getting access to elements is quite convenient

and as I said, they can even do a bit more than that

but we'll see them again throughout the course.

This is just an introduction

and this is all you need to know about refs right now.