Instructor: Our application is currently
in a pretty good spot.
If we enter in a valid email and password,
we successfully get back a JWT token,
which means we can make authenticated requests
in the future.
But what happens when we try to submit our form here,
our sign-in form, when say,
we didn't enter an email or password at all.
What happens then?
Well, we kind of predictably get a 400 here
that says bad request.
Basically, "Hey, you didn't even provide a email
or password."
We need to obviously provide some amount of information here
or some level of validation.
Let's also try entering, say, a valid email,
but maybe a bad password,
in this case, which we saw previously,
we get a 401, meaning,
"Hey, you put in a bad password here,
or perhaps the email you entered doesn't even exist."
So we definitely need to be handling some kind
type of error messaging here.
Something, the feedback, give feedback to the user,
"Hey, something just went wrong,
you should really try a different password or something.
Give it another shot and see how it goes."
So to do that, we will add another piece of state
to our authentication reducer.
We'll add another case in here,
that's going to handle any type of error that comes across,
any type of error action that comes into this reducer.
If it picks up an error, we can then show that error text
inside of our component and poof,
there's our error message all ready to go.
So adding another case to our reducer
means we'll need to add another type to our actions file.
So inside of types.js, I'm going to add another type,
and we'll call this one "export const
AUTH_ERROR".
(keyboard keys clattering)
Now I'm gonna close this,
I'm gonna close a couple other files
'cause I got just a whole bunch open.
I'm gonna go back into the index.js file
and look at the kind of the catch case here.
So this is the case in which,
you wanna show an error message to the user.
If you really think about it,
this is the sign-in user route, right?
Or the sign-in user action creator.
But we're very soon also going to have
a sign-up user action creator as well.
And chances are, it's going to need,
need to have probably nearly exactly the same level
of error handling, something to kind of take some error
and show it to the user.
So I'm going to, I'm thinking that it might be advantageous
that rather than dispatching an action directly in here
and writing the action directly in line as we did above,
maybe we should make a separate action creator
to handle the case in which
there is an error with authentication.
So let's give that a shot, see how it looks.
I'm gonna make a separate action creator
and I'm gonna call it "authError",
and I'm gonna assume, you need to pass it a string
that contains the error that you want to show to the user.
Then we will return from here, type
"AUTH_ERROR"
and a payload of the error string itself.
So error is error.
Let's make sure that we import this type into this file.
So up the top,
we will add in our additional type here
of "AUTH_ERROR"
like so.
Now, what we do have to do is make sure
that we call this action creator at the right time.
So the only time that we want to call AuthError right now
is really inside of this catch statement right here.
So this again is where
Redux Thunk starts to become very handy.
Up to this point and all the applications we've done,
we've only called action creators
from individual components, but this is a point in time
where we want to kind of call an action creator,
only in this kind of very specific case
that's nested inside another one.
So to do so, we can just add
dispatch authError,
and then pass in whatever error message we want right here.
And so I think I'll do just a
very straightforward error message.
We'll just hard code it to say "Bad login info."
So now, if the user makes a login attempt that fails,
or excuse me, a sign-in attempt that fails,
we will dispatch an action
that contains a payload of bad login info.
So this looks pretty good.
All we should have to do now is update our reducer
to handle this action
and then we can go back to our component
and make sure that the error message gets shown.
Let's take care of that part two in the next section.
I'll see you there.