Instructor: So we've got our form on the page.
We can collect a user's email and password.
And whenever the form gets submitted,
we call our event handler, handleformSubmit,
and we console.log the email and password.
So in the entire app so far,
we've been doing a lot of the, you know,
mostly repeat material.
Stuff that we're already pretty darn familiar with.
And we know how to put forms together.
We know how to make components,
we know how to use React Router, all this stuff.
Yeah, pretty straightforward.
So this is where we're starting to go into the realm,
of authentication.
When a user submits the form,
the expectation is that a couple things are going to happen.
We need to validate,
and make sure that the email and password are correct.
You know,
so we need to actually submit them to the server.
And the server's going to tell us, yes they are,
this info is correct, here is a JWT token.
Or no, it's not correct.
You know, email is wrong, password is wrong,
any of a million different things.
So, we need to start to kind of handle this case, you know.
Figure out how we're going to handle,
submitting this email and password to the back end.
Whenever we make, have made a AJAX request in the past,
or any type of request in the past,
we've always stuck that logic into an action creator.
And so that, that's still going to happen here.
You know, we're still going to use an action creator,
to make the request.
But the very important thing to note is that,
in every single time that we've had an action creator
so far, there's always been kind of a singular action,
or single singular flow that's come out of that.
There's been no branching logic whatsoever.
So we've never really had to handle the case,
in which say, a user posted a email and password,
and the password was incorrect.
We've only ever handled the case, you know,
where everything worked as intended.
And so, at this point in time,
we need to start thinking about,
how we deal with air handling.
So let's look at a diagram that illustrates the flow
that a user is going to go through,
once they submit an email and a password.
The very top.
We start off,
where a user is going to submit their email and password.
That info will be submitted to an action creator,
and the action creator is going to submit that,
to our server.
The server's then going to decide,
whether or not the info is correct.
And so that can be, you know,
is this email exist in the database,
is the password correct?
You know, all those kind of good authentication checks
that we've already wired together.
Depending on whether or not the info is correct,
we get two completely different scenarios.
If the info is not correct, all we want to do,
the only thing we want to do,
is show an error message to the user.
But in the case, that the info is correct,
and the server returns a JWT token,
then an entire range of different things are going to occur
inside of our application.
We need to redirect our user to /feature, you know,
that kind of protected route that we discussed earlier,
in the wire frames.
We need to update our application state,
to reflect that the user is currently authenticated.
And third,
we need to save the token that gets returned
from the server.
So there are three completely different,
very separate actions, or kind of side effects that occur,
when a user is successfully authenticated.
When they successfully provide email and password.
So not only do we have this kind of branching logic,
inside of our action creator.
In the positive case here,
we also have multiple side effects of our application.
So you can really juxtapose that,
to all the other action creators that we've created before.
Where it was like, one action creator you would call it,
it would return a single action,
and then a single reducer would pick up that single action,
to make a single change in the app.
So we're now starting to go into the realm of,
one action creator.
It's going to result in several different changes,
inside of our application.
We want to redirect the user, update our state,
and save our token.
So three separate and distinct things.
So this is the big challenge behind authentication,
especially in a Redux application.
It really tips the entire Redux model,
kind of in its on its head a little bit, you know?
It's kind of, very different than a lot of the more,
plain, vanilla interactions that we've been used to before,
where we were say, creating resources,
or editing resources, or deleting resources.
Anything like that.
JBT, or excuse me, authentication,
starts to really kind of throw a wrench
into that whole plan.
So enough talking about the challenge,
let's actually tackle it, so to speak.
As we saw in the diagram,
we definitely need an action creator.
And so I think that, definitely the best place to start,
is to put that action creator together.
Just something that we can actually call,
and probably, you know, make our request,
and figure out, okay, we made the request,
and you know, now what do we do?
So, you know, let's kind of put,
that next little bit of logic together,
and then we'll worry about how we,
make several different changes to our application,
when this action creator is called.
So for any action creator,
we always start off by making our types file,
and then creating our action creator
inside of our index.js file, in the actions directory.
Let's kind of go into a little bit of a different path,
than we have in the past,
where we would first create a type.
This time around, let's first make our action creator.
And we'll see why in just a little bit.
So inside of index.js, inside the actions directory,
I'm going to create a new function, called, signInUser.
And I'm going to assume that this is going to be called,
with an email,
and a password.
So whenever this action creator is called,
the assumption is we're going to pass in specifically,
an object, that contains an email property,
and a password property.
Okay?
So, inside this action creator, we want to, you know,
definitely do a couple different things.
We want to,
submit email,
password to,
the server.
If request is good...
We need to,
update state,
to indicate,
users authenticated.
We need to save,
the JWT token,
so that users can make authenticated requests in the future.
Remember, that's the entire point of the JWT token.
It's how we figure out,
or it's how we make follow-up requests to the back end,
that are authenticated.
And finally, we need to redirect,
to the route /feature.
And again, this kind of redirect right here,
to /feature, is just very particular to our application.
If you're making a different app,
that serves something else, you can, you know.
This will be very easily customizable in the future.
And then we also need to handle the case,
if request is bad.
What do we do then?
If the request is bad,
we need to somehow show an error to the user.
Okay?
So again, this really starts to highlight how different,
this action creator is,
compared to the ones that we've dealt with in the past.
In the past it's always been,
make the AJAX request, return an action, that's it.
Nothing else.
No other action here, no other side effects,
just a very straightforward approach.
But this time around, not only do we have branching logic,
we also have several different things
that we want to achieve, when the request succeeds.
So, for all the requests we've made so far,
we've been using the library called redux-promise.
Where we would just create a request,
return it on the action,
and then our data would kind of magically show up
inside the reducer.
So that is definitely, probably going to kind of not be,
exactly the approach we want here.
We want something with a little bit more power,
a little bit more oomph.
Something that gives us a little bit more flexibility,
to kind of dispatch different actions,
or, take different, you know, responses,
or handle this data differently,
depending on what comes back from the server.
So again, that's the big challenge that we need to fix here.
Let's continue talking about this, the problem,
and what we're going to do to solve it,
inside the next section.