Original subtitles

So attached you'll find this project here.

You can simply download it, extract it,

run npm install inside of it

and then npm start and you will see

this page on localhost free thousand.

Now that's a very simple dummy app where

you can enter any credentials of your choice.

That's not a real authentication screen yet for the moment.

It's just a dummy screen.

As long as you have a valid email address

and a password that is at least seven characters long

you can click the login button

and you're on this dummy welcome screen.

These links won't do anything

but the log out button will take you back.

So it's a very simple dummy app.

At the moment,

there is no real authentication logic.

We'll dive into that in a separate module.

But it is a good enough example to practice the use

of fact hook and side effects they offer

and also the Abra code concepts of this module.

So what's up with this use of fact hook now.

Well, what could be a good side effect here?

Sure.

We could send a HTTP request to a backend server

which validates our email and password

but at the moment we have no such server.

So therefore I wanna do something else.

At the moment when I log in with any dummy credentials,

which are an email and at least seven characters long

for the password.

If I click login, I am logged in in this dummy mode

but if you reload this page here

you'll always lose this login status.

And that is probably not something you want.

Now in reality you would of course, once you login,

send the request to the backend

and get back some log-in data for example,

some token which identifies this user as authenticated.

Again more on that in the authentication module.

But you wanna make sure that does this user

is authenticated status is also still there

once you reload the page.

At the moment we lose this because in the app.js file

where I manage this simple isLoggedIn state,

it's just managed as some react state.

And therefore it's just in the end,

managed in some JavaScript,

the variable behind the scenes by react.

Now the nature of that is that

when you reload your application,

your entire react script restarts

and all variables from the last execution are lost.

That's how the web and scripts and the browser works.

This is nothing react specific.

Now, since we lose all the data, when this restarts

it would be nice to store it somewhere

where it persists the reload.

And even better than that,

we also want to make sure that whenever this app does start,

we check if the data was persisted.

And if it is we log the user in automatically

so that the user doesn't need to re-enter the details.

And that's where we can use useEffect.

Now let's start with storing the data.

Here in the logged in handler,

I set isLoggedIn to true.

And that's where I wanna store that piece

of information in the browser storage.

Now the browser has multiple storages we can use.

The most common storage for this

would be cookies or local storage

and since it's particularly easy to work with,

we will use local storage.

So that's a storage mechanism built into the browser

totally independent of react.

Here in the log in handler,

we could therefore run local storage.

This is a global object which is available in the browser,

set item, and then give the item

any identifier of our choice,

like for example isLoggedIn

but that's totally up to you.

It should just be a string though.

And the second argument should also be a string

which you store.

And for example that could be one to signal

that the user isLoggedIn.

Zero could stand for not logged in.

Of course you could also have some identifier like this.

This is totally up to you.

I will work with one and zero.

So we can set this item here.

And if I do this and I save everything.

If I do log in again here,

I can open up the developer tools they're after

and there open the application tab or the application part.

There you'll find the storage section with the local storage

and if you expand this you'll find your host

and there you should now this key value pair.

That's stemming from this line.

So that's how we can store data.

Now we can do this here in the function

because it is a function that executes

only when the user clicks the button,

which is rare enough and which is exactly

when we wanna store something.

So that's now a use case

where we don't need useEffect necessarily.

But how about the scenario that the app restarts

because the user left the page and comes back

or simply because we reload the page.

Then we wanna check if in local storage

we have that key value pair.

Now when the app restarts

this app component function runs again.

Now therefore, here of course in this function,

we could reach out to local storage

call get item and search for isLoggeedIn

and this will return the items stored there.

So that's the storedUserLoggedInInformation.

That's a super long name obviously.

I just wanna make it clear what's in there.

You would typically use a shorter name, of course.

And we could check if the storedUserLoggedInInformation

is equal to one.

And if it is equal to one,

we could call setIsLoggedIn and set as to true.

So that we set the user to LoggedIn

even without this function being triggered.

And it would trigger

upon pressing the login button normally,

just because we know that the user is logged in.

And of course we should do that after calling useState.

So we could do that.

But the huge disadvantage with that approach is

that we would create an infinite loop.

Because we check for this being stored.

If it is stored, we set this to true.

And whenever we call a state setting function

this component function re-executes

and therefore this would run again

would find one would set it again and so on.

That's what I explained earlier.

So we need to use a fact here

because data allows us to control windows runs.

Hence from react, besides useState

we import useEffect like this.

And then here we can simply call useEffect just like this.

And now we pass those two arguments

you saw on the slide to it.

The first argument is a function.

For example here and anonymous arrow function.

Doesn't have to be an anonymous arrow function

but often you use just such a function.

The second argument is an array of dependencies.

Now I'll come back to those dependencies later,

but for the moment let's just write it like this.

In this function,

we can now run this code here,

which we don't wanna run directly in the component function.

Because now this function here is executed by react

and it is executed after important,

after every component re-evaluation.

So whenever this component function ran thereafter,

this will run.

And if you then update the state in here

the component will run again.

But it will not just run after every component evaluation

but only if the dependencies here changed.

Now when the app starts for the first time

that will be the case.

If this component function runs for the very first time

because your app just started,

then the dependencies are considered to have changed

because you had no dependencies before you could say.

But once it ran for the first time for example,

with this setup here,

we have no dependencies but therefore of course

they also didn't change compared

to the first execution cycle.

So therefore this anonymous function here

would indeed only run once when the app starts

because thereafter the dependencies never change

because this year specifically has no dependencies.

And in this scenario, that's exactly what we want.

We want to run this code once

and that's when our app starts up.

So therefore here we should have exactly

the behavior we want.

Once the app started, this code runs.

Here we update the state

and as you learned this triggers

this component function to run again.

Now they offered this all runs again,

this chair's is X code is evaluated and the dome

is updated accordingly

but thereafter defect would run again

but only if our dependencies also changed.

And that's not the case here as I explained.

So therefore digit only run once.

And hence if we saved that

and I reload here you see I am logged in.

I don't end up on the authentication screen

but in the logged in state.

And the reason for this is that we have this stored.

Now if I clear that manually by selecting it

and deleting it.

If I now reload you see I'm back here.

Because this code still ran

but of course it didn't find a logged in information.

If I do login again so that this is stored,

you will see we're back to the behavior from before.

If I reload, I end up on this page.

So that's user fact.

And that's one scenario where it shines a lot.

This data fetching is a side effect.

It's not directly related to the UI.

Of course the result is

but not the data storage access itself.

And we wanna run it as a side effect with useEffect

in this case to a wide and infinite loop

and to make sure that this code

which potentially could also be performance intensive

does not run for every component re-render cycle

but only if we wanted to run.

Now, let's refine our data storage example here

by also making sure that when we click the log out button

we again reach out to local storage

and we remove the isLoggedIn key there.

Simply to clear it from there

so that we don't have to clear it manually

by selecting it here.