All language subtitles for 006 Lifecycle Methods In Action_en

Now to convert the user finder

to a class-based component,

I will again import component from React,

and then the final class named user finder

which extends component of course.

Now in here, we need a constructor

because we got some state which should be initialized

by setting this state to an object.

Now here, I actually got two state slices,

the entered search term and then the list of users,

and therefore I'll add my filtered users here

and set that equal to dummy users

and then add my search term

and set this equal to an empty string initially.

Next we got a function here to search change handler,

which I'll implement as a method in the user finder clause.

Because that is then, the function, the methods

that should be executed to update the state.

At least a part of the state,

it should update that search term.

Now we get to event object here

because this is bound to the change event on the input,

and we then use the event object to read

the value entered by the user,

and therefore, we can expect this event object here

as well, to then set our state important here

always to an object, which is then merged

by React and updates the search term part

of that state to event target value.

And only that part.

Again, it will be merged,

so the filtered users, won't be lost.

Of course, we also need to add a render method

where we should return our JS X code.

So grabbed this return statement and add this here as well.

In here, I should point at this search change handler

and also to ensure that this keyword works correctly

in the method, bind this as explained in the last lectures,

and here for the filtered users,

we should refer to this .state.filteredusers.

And with that, we transformed this component.

At least almost one crucial part is missing,

and that would be the use effect function here

which we can't use in a class based component.

Now we could derive our filtered users

and set them in our state update

here in the search change handler.

That would be possible.

But I wanna show you how these lifecycle methods work

and therefore I'll use an alternative approach.

We can add component, did update here,

and this method will be called automatically by React,

whenever this component is re-evaluated

because it's state changed, for example.

So therefore in here we could set our new state

for the filtered users.

So here we can copy this logic

from the user finder functional component,

and call this set state to set the filtered users equal

to dummy users filter and so on.

However, if we want to do it like this,

we would create an infinite loop.

Because component did update is now executed

every time this component changed.

When we set the state, the component will change.

So then this will execute again

and it will change the state again.

And it will execute again.

You get my point, this would be an infinite loop.

Therefore, what we need to do is we need to check

whether the state we're interested in changed.

In this case if the search term changed.

For that component did update receives

two arguments which help us.

The previous props and the previous state.

So the last props and state snapshot

before the current component update.

And with that we can check if prevProps search terms

with search term was different,

then the current search term.

So this state search term,

only if it is different.

So only if the search term changed,

I wanna execute this logic.

If something else changed, like for example

the filtered users, which we are updating here

by calling set state, this method component did update,

we'll run again, but we won't make it into this if block.

So we won't update the state again,

and we won't have an infinite loop, therefore.

Here by the way, it's not all to be this state search term.

And now with that,

we replace use effect with component did update.

This also shows you how nice use effect is.

It's very short and by specifying the dependencies here,

we don't have to add an if check inside of it.

We need to add an if check here

for component did update, to prevent an infinite loop

but we don't need to do this with use effect

because we specified search term as a dependency.

So automatically this affect function will only

be executed by React if that dependency changed.

And our changes and other reasons for this component

to re-render are ignored for this effect,

because of this dependencies array.

Now, one thing I just noticed by the way,

of course I don't wanna compare prevProps, but prevState.

The previous state search terms should be compared.

If you would be updating based on prop changes.

So you got some new prop values

and you wanna add the component there for updates,

then you could compare previous props to current props

but here it's the state change, which matters to us

the state change inside of this component,

and hence we compare our previous state,

a specific slice of that state with the current state

and that specific slice of that state.

Now we should also add super in the constructor by the way

before we forget this, and now we transformed this component

and we can hence remove user finder

in the functional forum or simply comment it out.

And now if I go back this again, works as before,

but now with class-based components

and component did update.

And as I mentioned before in this module,

it's a different mental model.

When you work with these lifecycle methods,

you primarily think about when will this method be called.

Which is the case when the component updates.

And then you might need to add if checks

to restrict your logic in there with use of fact

you don't care about

whether the component is rendered for the first time

or if it updated or whatever, you care about

the fact that search term changed.

And whenever that changes, you run this logic.

Which is a very simple mental model in a positive way.

Nonetheless, you could use components did update

and state, as you saw here.

Now, besides state we also got ever life cycle methods,

most importantly component did mount

and component will unmount.

Now let me show you these life cycle methods as well.

Let's say our dummy users are loaded

from a server from a database.

So we're sending an HTTP request.

We're not doing that here,

but let's imagine we're doing that.

So initially filtered users might be an MTRA.

Then when the component is rendered for the first time,

we wanna send a request to the server.

Hence we can't use component did update in this scenario

because I don't wanna fetch the users over and over again.

You might need to do that in other apps

but not in this imaginary example.

Instead, we wanna fetch the users

when this component is rendered for the first time,

and that is something we would typically do

with component did mount.

You add component did mount like that,

and then in there you could send your age

to http request and handle all of that,

and eventually you would update your state

and set your state in this case

to set filtered users to dummy users,

which might've been fetched from some server.

Again, it's just a dummy example here.

That's what you could do.

We don't need an if check here

because component did mount will only run once

when the component initially was rendered

for the first time.

If then is updated thereafter,

component did mount will not execute,

instead, components did update will execute.

So therefore that's how we could write this,

and if we do, we essentially got the same result as before

but now we're loading this when the component is mounted.

The equivalent to that in the functional component world,

would be to call use effect

with no dependencies or even with dependencies,

it would execute this function when the component is mounted

for the first time, because it's treats the dependency

as to have changed if we had no dependency before

because the component wasn't rendered

and now it is rendered and different,

we do have this dependency.

So to use a fact function will also always execute

when the component is initially mounted.

Now last but not least, we have component will unmount,

and I can show this method in the user component.

Because the list of users is rendered conditionally,

so it is actually removed if I click hide users.

Therefore, in the user component,

which has also a class-based component,

I can add component will unmount,

and in there I'll just console log user will unmount.

And if we now save this and go back

and open the developer tools,

here, like this,

if I click hide users,

you see user will unmount three times.

Why three times?

Because we used the user component three times

we rendered free users in the end

and all free instances offered component were removed

and all these life cycle methods are run

for every component instance, of course

just like user effect

at state work for every component instance stand alone.

And these are the lifecycle methods.

It's a different mental model, but in the end with it

you can of course achieve the same

as you can with these React hooks,

with use effect and so on.

It just as a bit more a code

and it could be the more difficult mental model.