All language subtitles for 044 React Lifecycle Methods - Updating_en

Now that we've taken a look at the mounting phase of our component after our component has been mounted

onto the dam, any future updates either to the props to the state?

Or us manually forcing an update on our component.

Will cause our component to go into the updating phase.

So what is the updating phase and what triggers updates?

Well, if, for example, inside of our app Jass, we're passing in the text value off of this dot state

right into our lifecycle method, which for us is the string where whenever we click the button, we

just append underscore hello to that string.

We just make it longer and longer.

Right.

Which we can see right here.

Every time we update and click this and update our state and this new state value gets passed into our

life cycle component.

Our lifecycle component goes into the updating phase and it's like, oh, I got new props, I should

probably re render my component, not Rimando or component is already mounted.

It doesn't need to go through mounting again.

It doesn't need to be destroyed because REACT doesn't want to create new elements for doing that is

actually very costly on the browser.

But selectively changing pieces of the HTML inside of our component is way easier because all it needs

to change is this stop props that text.

It doesn't need to change the H3.

It doesn't need to change the div.

So reacts like, OK, I'm just going to update this stuff.

Props that text.

Right, or I'm also going to run through those lifecycle methods that might be affected in this updating

phase because the props have changed and maybe these lifecycle methods do use the props to do something.

Right, that's all up to us and how we want to write our code, the promise of change.

I'm going to start going through my update cycle.

The update cycle could also be triggered if this dot set state gets called inside of our component.

So we don't actually call that state inside of our life cycles class because we don't have state.

Right, which is fine.

But if we look at our app component, we do have state and we do cost that state whenever we click either

of these buttons.

So whenever we click one of these buttons react, we renders this component as well.

It goes through the update phase of our app component as well, because there might be things inside

of our component that depends on the state to determine what they need to do, including our render.

If, for example, we were displaying this DOT state.

Text inside of our component ourselves, the component needs to decide, OK, I should probably render

because there's a chance that this component is rendering something on the state.

So that's why it does it.

It's like, OK, the components state has changed as well.

Let's also run through our update phase for our component.

And then finally, we can also force an update by calling this status update inside of our component

anywhere.

This forces the component to update everything.

It just forces to go through the update phase.

But inside of the update phase, it just.

Goes through these following methods, so just like our mount, right, it also goes through the render

again, because new props comes in or new state comes in, react has to go through its process of deciding,

oh, what in my component has changed.

And then it's going to update the dome, right, so it's going to update the dome with the changes that

are required in that component.

Again, we're not remounting that component, which is making the change, that piece of the component

where it's affected.

And then it calls component it update similar to component of Mt. It's the life cycle method that gets

called after the updates have been made to the DON.

And here.

We can see this.

When we click update, text, right, we see it called render, and then it calls our component it update.

One thing I want us to look at is actually this life cycle method, so I'm just going to put it in here.

It's should a component update.

Should component update is a cycle method that determines whether or not this whole chain needs to happen.

And it actually exists between these things that would trigger this updating phase to happen.

And the following Life-cycle methods to get triggered.

She component update actually sits right here at.

And what it does is it gets the props and then the next state, right, so it gets when props change,

they come in as a parameter or when state changes, it also comes in as a parameter.

And what happens is that based on the props, the new props that are coming in or the new state after

we've called said state, we can determine whether or not we want to go through these other life-cycle

methods, including actually re rendering our component right.

Because if we don't want to render a component, we don't have to.

And how we would do this is actually if we looked at our objects.

So, for example, whenever set state gets called, we know that what gets happened is our render call

gets called right in our component.

So whenever we call sad state, we're actually re rendering this whole abcess component, which actually

ends up re rendering the life cycles component, even if we were not passing this text in.

This component, because it's a child of our arpeggios, gets re rendered, I can actually show you

if I get rid of this prop so we're no longer passing the prop into our life cycles method, even though

I click update text.

You will see that our render method and then component, that update is getting called from a life cycle

component.

This is because of how reacts, no tree works, react, knows that inside of this component, any of

the children might need to be rendered because it's just going to assume that everything in the render

is affected possibly by the state changing or new props coming into this component.

Right.

So whenever a component gets updated rendered, all the children also get re rendered.

And this happens whenever, again, as we saw props change or sets state gets called or force update,

it's called inside of the component.

Now, the reason this is important is because let's say we called set state on a property that are life-cycle

method doesn't care about.

Let's say, for example, we had another state property, I don't know, message.

Right.

And then this value we used somewhere else inside of this component, we don't pass it on to life cycles

as a prop.

We just use it somewhere else.

Well, if at stake, it's called the upstate's this message we just saw that it's going to force our

component to update.

Right.

And our component.

If the state of Texas hasn't changed, why do we need to re render a life cycles component?

That's a waste of processing power.

It's it's slowing down our browser.

So what we could do here is it allows us to selectively hijack.

And not go through that Virender, right, we don't have to render our component.

And here we can see we do that by what gets returned as a boolean value from should component update

if we return.

True.

Then our component will update, it will continue, will go through the cycles, and it will run through

that component and update.

And here we actually see us logging the next prompts that we're getting, right?

So whenever we collect update text, we see that the text is coming through.

Right.

That's the property, the new text property that we're getting.

But if we return false.

What happens is that it doesn't even go through any of those lifecycle methods except for a component

update.

Because when we return, false, we're saying, I don't want my company to render and the reason we

would do this is, for example, if we were to check the next props that we're getting, if we see that

the string value for our text has not changed, then we don't care to update them.

We don't need to.

There's no reason for us to do that.

And here we will see that if we click up the text, we're getting this call, our component update.

But because we're trying to false, it does not go through the next cycle methods that need to happen

inside of our updating phase.

And the reason we would do this, as I mentioned, is because maybe we don't want to remender because

our techs didn't change and we can actually force this to happen if inside of our button click instead

of a pending hello, we just keep the text as what it is.

But because we're calling set state, we're forcing the state to change and because we're forcing the

state to change or forcing react to re render our component.

So now inside of our lifecycle methods, what we can do is here we can actually say we want to return

instead of force.

We want to return.

If next Prof's text does not equal this stop props dot text.

So if the current text is the same as the next prompt text, then don't render because there's no point

to write.

We don't need to render our component because our props have not changed.

So now we'll see if we click update, text.

It doesn't update.

But if we go back and we say that, OK, now the text is changing.

Well, then our component will update accordingly.

So this is mainly just for performance.

If the property's coming in are not different than the props that we already have, then there's no

reason to render.

Now, understanding this update phase is so fundamental to us becoming better react developers, because

much of how code is structured and how the architecture for react is written is based around this update

phase, because this is fundamentally what the Riak Library does for us.

This is why we write components.

This is why we break our code up the way it does, because this update phase is how Riak makes our lives

easier for us whenever it updates the DOM.

Based on new properties coming in, based on us calling substate or forcing updates inside of our components,

this triggers a chain reaction of, for example, our app component, updating also its children, not

only rendering itself, but rendering any child components it has.

And then those components also update.

But that's the thing, if we trigger big updates like this, there may not be a need to even update

these components if, as we saw, the props do not actually change, if the props don't change, nothing

about this component needs to update.

So leveraging the life cycle methods will allow us to possibly improve the performance of our application,

but also give us a better idea of when we should do what with our components.

Now, of course, we're going to practice more and more with writing our components, building react

applications.

But just thinking and keeping this in the back of your mind as we code will help you better understand

why we structure the code the way that it is.

This will all make more and more sense the more you code in react.

Now, I know this was a bit of a longer lesson, but now that we understand what the update phase,

let's move on to the last phase, the UN mounting phase.