Instructor: In the last section, we wrote out our
simulate-change event handler right here,
and we made sure that we passed in a fake event object
that will be provided to our callback function.
So now, we get to move on to the next step in this diagram.
So on here, we had said that we were going to
attempt to force the component to update.
And when we went through this checklist right here,
originally, I had kind of skipped over this step right here.
So now, it's time to talk about
why we need to actually force the component to update.
So the reason is actually kind of straightforward.
Let's go back to our actual component definition
inside of our CommentBox file
and we'll take a look at that event handler.
So here's CommentBox,
and here's our handleChange event handler.
So remember, when we reviewed
how this entire component worked a moment ago,
we had said that setState gets called right here,
and that forces our component to re-render.
When it re-renders,
we take the new value of this.state.comment
and shove it into the text area.
Now, the key step in there
is that we want our component to re-render automatically
when we call setState.
And as we very well know about React,
anytime we call setState,
boom, our component automatically re-renders.
But there's a tiny little detail in there
that you need to be aware of.
When you and I call setState,
it triggers our component to be re-rendered asynchronously.
In other words, when we call setState,
it does not cause our component to instantly re-render like,
right here, right away.
Like right here, re-render.
It does not instantly occur.
Instead, it queues up a request for an update
inside of React.
And React says,
"Oh, it looks like someone just called setState.
Yeah, I'll get around to updating that component
when I feel like it."
And so that might be at some point in time in the future.
So when you and I
get this handleChange callback right here called
and setState is invoked,
it does not immediately update our component.
And that's an issue for you and I
with our test file over here
because the instant that we simulate that change
right after that line of code,
you and I want to write an expression
that immediately looks at that component and says,
"Oh yeah, the new value is now available."
So we cannot do that instantly
because setState is asynchronous
and we have to kind of wait
for the actual re-render to kick in.
Now, in order to get around that,
in order to make sure that you and I
don't have to wait for the re-render to be issued by React,
we're going to, instead, force our component
to automatically re-render itself.
We're going to force it to re-render.
So that's the purpose of this step right here.
We want to make sure, 100% sure,
that that component re-renders itself
and a new value is shoved into that text area
so that we can then write an assertion.
Now, to force the component to update,
fortunately, Enzyme, again, has our back.
So if we, again, go look at the Enzyme documentation,
we can find,
where was it?
U's, we're looking for U's.
Update right here, towards the bottom.
So if we call update on a reference to a component,
that will force the component to re-render itself.
And that's pretty much it.
So back over inside of our test file,
after simulating that change event,
I will call wrapped.update.
Like so.
And then right after that, so like right here,
we can actually write out our assertion
to look at that text area
and make sure that it has received the correct value.
And in our case, the correct value
is going to be the string of new comment right here.
Because that's, essentially,
the value that we tricked our component
into thinking that it just received.
All right, so let's take a quick pause right here.
We'll come back in the next section,
and we'll figure out how to actually write the expectation
that we'll make sure that the text area
received the appropriate value.