This course has been updated! We now recommend you take the Intermediate React, v5 course.
Transcript from the "useRef" Lesson
[00:00:00]
>> Brian Holt: Okay, let's go to ref.js. So this is where, in my opinion, this starts getting hard. So I have this useRef example here and if I click delay logging.
>> Brian Holt: Notice that it says, you can see right there it says, state one ref one. But notice this says in the alert, state zero ref one, okay?
[00:00:27] And I want to show you here increments in delay logging which is the function that's actually doing the alert, right?
>> Brian Holt: The set state, I call that right away and I say set state plus one, right? And I say numRef current plus plus, you would assume that state number and current because they're always kept in locked step, right?
[00:00:50] Use state and use ref right here, they both start at zero and they're both incremented at the same time. They would be the same always, right? So why aren't they the same?
>> Brian Holt: Well this is kind of the problem that you run into, this is a problem with a closure, right?
[00:01:06] And if you don't understand closure super well, Kyle Simpson has a great course on it in Frontend Masters, so definitely check that out. But suffice to say that stateNumber here actually doesn't change. So I am setting stateNumber, and it is incrementing, and it is causing a re-render, right?
[00:01:22] So when I click delay logging, notice that state and ref both change immediately, right? But this state number from the previous iteration has not changed, right? And this closure is holding onto this state number, right? So what's actually getting logged out is the previous version of the state number.
[00:01:43] Watch what happens if I click it twice.
>> Brian Holt: Two and four, right? And the reason being is it's reading out of numRef.current, that's always going to be the exact moment in time, this is what that numRef's value is. Whereas stateRef for the state number is always being held onto the previous one, because of the closure holding onto that state.
[00:02:09]
>> Brian Holt: Does that make sense?
>> Brian Holt: And the reason why this context is being different is cuz we're doing a set time out and logging in the future.
>> Brian Holt: This is what Refs are used for. They're useful because they allow you, if you have a problem, where you have these multiple closure problems where you need to hold on to the same state.
[00:02:31] Maybe it's very important that this useRef be always the exact right one and it can be called in any context. That's when you would want to use a Ref, right? So if you were doing a class component, you would just make an instance variable in the class, and that's how we would handle that, right?
[00:02:46] That's how we've always handled that before in React,. But we don't have that ability anymore because this is no longer a class, it's a function, right? So useRef allows us to do that. So what useRef does is it gives you this object. And this object has exactly one thing on it called current.
[00:03:04] It actually will error if I try and say numRef.something else equals five. It says hey, this object is not extensible. So it actually literally limits you to only use current.
>> Brian Holt: If I say current, that'll go away, okay? They do that by sealing the object.
>> Brian Holt: Questions about Refs?
[00:03:34]
>> Brian Holt: So this'll be useful for things like holding onto DOM elements frequently. It's also useful holding onto timeouts and holding onto intervals so you can make sure that you get the correct one.