All right.
And once we're done setting up a log in and register functionalities before we move on to the nested
pages, let's address the elephant in the room.
Since both functionalities are so similar on the frontend.
Can we just refactor and get away with just one function?
And the answer, of course, is yes, yes, we can.
Now, before we begin with, just mention a few things first.
This is totally optional.
So if you are happy with the current setup, you can just move on to the next video.
The only reason why I decided to do it is because I know I'm going to be getting comments about this,
so I might as well show you my approach.
Second, keep in mind that if you ever do decide to add something to our auth approach, for example
verified email, it's easier if you have a current set up.
So my point is yes.
At the moment, there's quite a bit of repetition, but it's not always the case.
And lastly, when it comes to refactoring, it's always my preference to do it at the very, very end.
Basically, when I'm done building my entire app.
Otherwise, you might find yourself constantly rewriting your code.
As you're trying to add new features, and with that said, here's how I would refactor to one function.
And essentially the goal is falling where instead of six actions, there's going to be only three.
And instead of two functions registered user and logging user, there's going to be only one function.
So let's start here in the actions where in between the video, our remove these suckers.
But for now, I simply want to copy them.
Let's say a logging one again doesn't really matter.
I'm just going to rename it to a set up user.
So again, let me go with my multiple cursor here.
And then we're looking for setup and user.
So those are going to be my actions, game success and error.
Let's save this online.
Hmm.
I think I'm going to start here in the app context again in between the videos, our more registered
user.
When I simply want to do right now, scroll up.
Also, the imports, as I say, not so set up user begin set up user success and set up user error.
Now, once we have imported all of these three men just copy one of them.
Let's say a logging one is a good one to copy.
Let's copy and paste and this will be set up user.
And now let's keep in mind that what is the difference between these two functions?
Well, essentially it is too precious.
First of all, the end point is different.
So one has a logging.
The other one has the register and second in the reducer.
Remember when it comes to your success message in this case would go with logging successful.
And in this case, we go with user created.
So what is the approach?
Well, I can just pass in more parameters, correct more arguments into my function, my setup user.
Now again, this is my preference.
But usually if I have multiple arguments, I rather set it up as an object, so if I don't have to worry
about the order of the parameters.
So in this case, the object and I'll add two more things first, the end point.
So that is going to be either register logging.
So let's sit here and point.
And the third thing that I want to add here is the alert text.
So I'm going to go here with alert text.
And you know what?
Let me set this up as complicated as well.
So we have more consistency.
So let's say this one right now.
So that's my setup user online instead of post log in or register.
We will set up here virtual.
I'm Lance Bass and my end point.
So in one case, it is going to be the register and in the second one, it's going to be a logging correct.
And then when we're dispatching the success, here's what I want to do in the payload.
I want to pass in the alert and then text.
Now I do need to change these ones around, correct?
So everywhere where I have the logging, I'm going to remove and I'm going to say set up user and let's
save this one right now and let's keep on moving.
Why do we have the logging user now also passing set setup years or so?
Let's service one online.
One comes to reduce error.
That's right away.
Set it up.
So I'm going to navigate here.
And you know what?
Before I do that, I just grab them.
So it's a little bit quicker.
So let's go to reducer and online.
Import them here, and let's keep on scrolling.
Again, this is going to be the case where we want to copy and paste.
So we're looking for logging user begin all the way to the era1.
Let's copy and paste them, and we just want to change this around where we're going to go with setup
user.
And again, I know I keep saying this all the time in between.
The videos are among these ones.
I just don't see the point of doing that while I'm recording, so I'm going to go here.
Would set up user.
And the only difference here is going to be the fact that when it comes to alert text, it's going to
be located in action payload and alert text.
Everything else stays exactly the same.
So we're going to go here with action.
Then payload and an alert text and are not, of course, if you want to structure this, so the locations
and user and token from the action payload, you can definitely do so above the return.
My gosh, I'm not going to do that.
So let me just say this, and now we need to navigate to the register.
So we're looking for the registered one and none in here.
We want to grab our page.
So let's import our setup user and then let's keep scrolling and learn where we actually invoke it instead
of a logging user or registered user.
We're going to go with setup user and then remember, I set it up as an object.
So here's what I want to do.
I want to pass in the current user, since Iris is a member one.
Why do I want to?
Do I want to log in?
Correct.
So my end point in this case is going to be a log in one.
I'm going to go with logging.
And thirdly, we need to pass in the alert text, and this is the case where I want to navigate back
to the reducer.
And let's take a look at the logging one.
So that's going to be my text, and I'm just going to set it up here in the quotation marks correct.
And the same thing is going to be with a registered one.
Essentially, I want to remove it and I want to go with my setup user.
So passing the current user and point will be a register register and instead of a long and successful.
Again, just to speed this up a tiny bit, we're going to go with this one instead.
So back in the register, remove this one.
And yet now we have everything in place and just so I can test whether I have some dumb box or not with
me, navigate back through my front end, I have the register with me refresh now.
I did remove right away user or otherwise will navigate to the dashboard and let me register first.
So in this case, I'm going to go with Peter Beer at Gmail dot com.
I'm not a secret and moment of truth.
Whether everything works.
Yep, I created the user.
I'm redirecting grandma some arm in the dashboard so that I work.
So now let me remove it and let me go back to the register.
And now let's just out the functionality for logging.
So not John.
Or I mean, we could go John, but I just stick with beta online or go secret.
And what do you know?
Everything works, so that would be my approach of refactoring register and logging to one function
and only three actions.
But again, let me repeat something very, very important.
This only works since our functionalities are extremely similar.
We're just returning that user, token and location.
Once you start adding more features to us, like I mentioned, for example, email verification, it's
not going to be the case.
And it's actually easier if you have those two set ups in place, one for register and one for logging.
So those are just my two cents and now we can move on and start setting up nested pages in our application.