Beautiful.
And once we have the functionality on the back end now, let's also implement everything on the front
then.
And my apologies if this video is longer than the usual ones.
But the thing is, we already have pretty much covered most of the stuff in the previous pages.
More specifically, register.
So I kind of feel that there is no point on splitting this up.
And basically, here's what we want to do.
We want to set up a form with a profile.
And here we have four fields.
So name, last name, email and location.
Now what we need to understand is that by default, I want to set them up to whatever I have in the
user.
So the one that I'm getting with my initial request, where is it located?
It is located in the state or here.
Keep on scrolling notice.
We have the user object and here I have email, last name, location and name, and I will set this
up as a local state.
In this page, and I'll just use my user object for my default values.
So these are my default ones.
And then if I want to make some changes, I just fill out the fields and then we'll make a request just
like we did in the postman in the previous one.
And then if everything is correct, we update the values get new token and life is great.
Now, if one of ours is missing, I guess that we'll check in both places, so check on a frontend as
well as the server for the empty values.
Hopefully this makes sense.
And then eventually we'll use of this location when we're adding the job.
So again, that will be our default location when we add job to our database.
So let's go back to our project.
I'll close everything.
I'll open up to read me since I'll showcase what we need to do.
And the first thing in the app context, let's just set up a dummy function.
I'm that user.
This is world all passing the current user.
So there's going to be an object with bunch of properties and all that.
And then I just want to console.log the user.
So and then we also want to go with the value and then pass it down to the rest of our application in
our cash profile address.
And before we take a look at the profile address, let's set this one up where we want to go to our
client and source then app context.
And let's say right after the log out user, I'm going to go with update and then user.
Now it's going to be a cinch.
There's going to be a request.
We're going to go with current user and let's just go with log and then current user effectively in
this video, we'll just log it if all the values are provided.
So once we pass this down, meaning once we add here to a value as well, we want to navigate to profile,
which is located here in the dashboard.
So notice all of these pages.
We're looking for a profile and look for use state because it is my preference.
If I can't set this up as a local state, there's really no need in this scenario to add anything to
the global state.
I mean, we just have to form values.
We want to fill them out and then send the request.
Can you set it up as global?
Yes, but I really don't see the point.
And as far as the rest of the imports, I'm looking for form row because we don't have a form.
I want to get the alert two components we already worked on.
I want to get used up context, which is going to be equal, of course, to my app context.
And then for this one, the wrapper you're looking for is dashboard form page.
Why?
Because will we use it over here as well?
So essentially her to have one place for all the stars, one from the app context, I want to get user
and then a rest of the functions.
So color display update user and then he's loading as well.
And then, like I said, I will have a local state where I'll check for the user and I'll use the properties
as default.
And since there might be some instances where users now notice, again, we have this optional chaining
where I go with user and if the user exists, then I want to get the name and the same I have for email,
last name and location.
Now, as far as handles, submit will prevent a default, will check for empty values and then we'll
display the alert.
Now, while we're testing everything, basically we will be setting up the app request.
Since I want to showcase the differences between the errors.
We're getting back from the server and actually will come this one out because it's hard to showcase
what would be the response from the server with empty values if I'm already checking.
On a front then, so then removed temporary and then we'll add it back up.
And here I have the update user.
So if all the powers are provided, I'll pass here.
This object, the current user, and then it now forms a form.
We have here a little bit of styling, so form on cement equals to handle some high profile Charlotte,
just like can register.
And then we have a bunch of these form roles.
And I guess the only difference in this case between the former is that we have in a register and the
ones where we have in the profile meaning will set up in a proffer is the fact that since I don't have
one object.
In here, I have multiple use states.
I'm just going to go with whatever is the function.
I'm not.
I'm looking for the event just like we did previously.
Only the difference in the register, of course, is the fact that I was looking for it over here in
the function and then there the acrobatics in a falling way.
Now in the profile one.
And my apologies, I was actually looking for a read me in profile.
One will go set the name and then we need to go with our function because remember otherwise, it's
going to get invoked right away since we're passing here the values and we'll grab around that target
value.
Again, there's many ways how you can set it up.
I just wanted to showcase the other approach because now where you can implement it in your applications,
when we have labeled text for the first time.
Because now this year we're using name is equal to the last name because that's the state rather than
all the work in the bottom.
We have a button we type submit disabled as loading and equal to is loading and please wait and save
changes.