Original subtitles

So we saw useEffect in action,

here in the scenario with Node dependencies.

Now, often you need dependencies

because you don't just want to run this effect function once

when the app starts up

but indeed, after every component reevaluation

if a certain dependency changed.

And an example can be found in the login component.

That's the component where I actually render this form here.

This form here, that's being rendered here.

And as you see, there is actually some validation built in.

If I click in here and I click out,

you for example see this is marked as red.

And also the button is only enabled

if I have entered something valid in both inputs here right?

Otherwise the button is disabled.

So we get some validation and currently,

the validation works such,

that for every keystroke on the email field,

this emailChangeHandler runs

and it sets the form as valid

if the email contains the @ symbol

and the entered password was correct

and we get the same for the password change handler.

And I also got the validate email handlers

where I set email and password as valid

whenever the inputs blur, so whenever they lose focus,

so that they also are marked as invalid

if I just click in there, enter nothing

and click somewhere else.

Now, where could we use useEffect here?

Well, for example, to restructure our validation logic here

instead of having essentially the same logic

just well, swapped basically,

in the email and the password change handler,

we could use useEffect to have one place

where we mark the form as valid or invalid with one logic,

which should trigger,

whenever either the email or the password changed.

And that's where we will need extra dependency.

So therefore here, we can again import useEffect

and then here after our state definitions,

we can call useEffect and pass this first function to it

and have our array of dependencies.

Now in this first function, I will call setFormIsValid

but of course I will not use the event target value

but I will check if the enteredEmail includes the @ symbol

and the enterPassword is longer than six characters.

Now, like this, this would only run once

and that's when this component first is rendered.

So therefore if I remove that logic from the password

and the email change handler,

you will see that I can reload this and I can type in there.

And my form, well, this button never gets enabled.

And the reason for that is simply that,

this effect only ran once as I said,

when the component rendered for the first time.

Now that was the right behavior in the app component

with our login state.

It's definitely the wrong behavior here, though.

We want to reevaluate this

and rerun this form validation state setting function

for every keystroke in email and password change handler.

Now, we could remove the dependencies array.

Now don't save this because this would crash your page.

This would make sure that this runs

whenever this component was reevaluated.

The data for effectively in this case

it's the same as if we would have moved

this code directly here into the component function itself,

because now without any dependencies,

this code reruns whenever the component was rerendered

and since we set state in here,

this would trigger a rerender cycle itself

hence we would have an infinite loop.

So, saying nothing about the dependencies

is not what we want, but no dependencies

is all not what we want, then it would only run once.

Well, indeed there is a simple rule,

you add as dependencies, what you're using

in your side effect function.

So in this case, we are using, the setFormisValid function.

We are using enteredEmail

and we are using enteredPassword.

Includes and trim are only called

on those enteredEmail and enterPassword fields then.

So we have setFormIsValid, enteredEmail and enteredPassword.

These are our three things we're using here.

So therefore, here, between these brackets,

you would add, setFormIsValid, enteredEmail

and enteredPassword, just like this.

Important for setFormIsValid,

you of course don't execute it,

that would add the result of this function execution

as a dependency, but instead you added like this

to add a pointer at this function

so that you essentially add the function itself

as a dependency.

And this tells React,

that after every login component function execution,

it will rerun this useEffect function

but only if either setFormIsValid,

or enteredEmail or enteredPassword,

changed in the last component rerender cycle.

If neither of the three changed,

this effect function will not rerun.

Now actually, you can also omit setFormIsValid

because those state updating functions by default

are insured by React to never change.

So these functions will always be the same

across rerender cycles, so you can omit them.

enteredEmail and enteredPassword

could have changed of course.

To be precise, with every keystroke,

one of them will change.

So if we now save this and we try this again,

you see the login button still enables and disables,

and the reason for that is,

that now useEffect function reruns

whenever enteredEmail or enteredPassword changed.

So that's another scenario where useEffect shines.

It helps us make sure that we have one code,

in one place, instead of as before in multiple places

which reruns, whenever one of the dependencies changed.

And that's also something where you use useEffect.

So it's not just for when a component

was created for the first time,

but it's equally common to use it to rerun logic

when certain data, typically some state

or some props changed.

Now, one aspect that could be confusing here,

is that of course now, inside of this useEffect example,

we're not working with local storage.

We're not sending an HTTP request.

We're not setting a timer or anything like that.

Instead we are updating the React state

and that could be confusing if you'll recall

that slide from earlier,

where I had a slightly different separation.

So to clear that confusion, you must not forget,

that it's called useEffect, and it has one main job,

it's there to handle side effects

and often side effects are http requests and so on,

but it's also a side effect,

if we listen to every keystroke and save that entered data

as we're doing it in the emailChangeHandler for example

and we then wanna trigger another action

in response to that.

So checking and updating that form validity,

in response to a keystroke in the email

or a password field,

that is also something you could call a side effect.

It's a side effect of the user entering data.

So that's why this should not confuse you.

useEffect in general, is a super important hook

that helps you deal with code

that should be executed in response to something.

And something could be the component being loaded.

It could be the email address being updated.

It could be anything, whenever you have an action

that should be executed in response to some other action,

that is a side effect

and that is where a useEffect is able to help you.

That's just a little addition I wanna make here.