-: In the last section, we attempted to create an account
but we, we didn't really see any AJAX requests
come across the wire here.
And if you were testing at home,
you probably saw an error message that looks something like,
'this.props.signupUser is not a function'.
And so that means inside of handles Form Submit.
We tried calling 'signupUser' right here,
but we got a big error message saying,
'Hey this thing isn't a function.'
So I think that we made a little bit of a mistake,
down at the very bottom of our file.
At the very top, we imported our actions,
but we never actually added them
to our reduxForm helper here.
So remember when we're using the reduxForm helper,
we add our actions as the third argument.
So let's now give this another shot inside the browser.
I'm gonna say test123456,
password and password,
sign up.
And it looks like we successfully made our request
and got a token from our backend.
Awesome.
So this is looking pretty good.
Let's do something a little funny now.
And I just successfully made this account.
Let's see what happens
when I try to make another account again.
Okay, so you'll see now I get a 422 error here,
which means unprocessable entity, it means,
hey the server got your request,
but wasn't actually able to create a record,
because the request that you made doesn't really make sense.
So if we click on the request itself
we get an error back that says email is already in use.
Which is exactly what we would expect coming
from our backend.
So this is looking pretty good.
We can now make use of this error message
when it comes down to it.
So I'm gonna flip back over to our action creator.
We're definitely making the request successfully here.
We're seeing it come across.
So let's implement very similar and probably identical
logic to our sign in helper.
When the request is successful,
we want to change our authenticated piece of state to true,
we want to save our token,
and we want to redirect our user.
So in the .then case,
we're gonna get a response back.
And first I want to,
let's just take the same order here.
So the first thing I'm going to do is dispatch a new action.
So I'll dispatch
an action of type:
AUTH_USER.
So that's gonna flip my authenticated piece of state
to true.
I want to update my token,
localStorage.set
Item
token,
to response.data.token.
And finally, I want to redirect my user.
So again, I'll say browserHistory
.push
feature.
Now we need to consider the fail case here.
The case in which, hey, like you made the request
but maybe the emails already in use,
or who knows what else could have possibly gone wrong here.
So we'll also add in our .catch case,
where we will take our response.
And in this case, we'll dispatch authError.
Remember, authError is an action creator.
All we do is we pass it a string
and that's going to send
an error message down to all of our different components.
And so in this case,
we want a very particular error message.
We want the one coming off the response here.
So let's say response
.data
.error.
All right, let's kind of take this error handling logic
all the way through to conclusion.
If you recall, inside of our AUTH reducer,
we are already picking up this AUTH_ERROR message
right here.
So error is action.payload.
That means inside of our signup component,
we should be able to very similar, in a very similar fashion
to our sign-in component,
we should be able to create a map state to,
map state to props function,
which is just gonna pull off that error message,
and display it to the user if one exists.
So we will create a new function
mapStateToProps,
it'll take our state.
And then from here we will return
an errorMessage,
state.auth.error.
Now inside of our component, or at least
in the Redux Form helper,
we'll make sure to add mapStateToProps.
'Cause I've been forgetting this left and right.
Now, inside of our actual component,
we should have, have access to
this piece of state or this prop, excuse me,
called this.props.errorMessage.
And so just right above the button
I think would be a good place to show this.
We're gonna follow a very same pattern that we used
in the sign in component.
And so right about the button I'll say
this.render
Alert,
and make sure to invoke this helper.
And then we'll add a little render helper here,
renderAlert.
And I'll say, if this.props.errorMessage,
then return
a div with className,
alert
alert-danger.
And just identical to the sign in
we'll add a strong tag
that should say 'Oops!'
And this.props.
errorMessage.
Cool. So let's save this and give this all a shot.
So at this point in time, we've added in some
handling for any errors coming from the back end.
And if the create account request is successful
we should also see a redirect
over to the feature route that we've declared.
So let's do a refresh.
Looks like I probably have a typo somewhere.
I'm gonna flip over to my console
Scroll up, see the error, and it looks
like I accidentally put an L instead of a semicolon.
I'll tell you, talking and typing is
harder than you might think it is.
So inside of
sign up component down at
mapStateToProps,
I've got an L here, I gonna replace it with a semicolon.
And now it looks like the bundle is valid.
So we can give this a shout out in the browser.
So let's handle,
let's see what the error case looks like first.
I'm gonna put in password, or excuse me,
a test123456.
So I just created an account with this exact same email.
So I'm going to expect to see a red error message here
that says, 'Hey, sorry, but this email is already in use.'
So I'll click oops or I'll click sign up
and I see, 'Oops, email already in use.'
That's perfect.
I'm going to update the email.
So I'm just gonna add in a seven now.
I'll click sign up.
It looks like the request was successfully made.
and I got my redirect to feature.
Now again, feature is not actually a route
that we've defined just yet.
So we'll need to take care of that.
One thing that you might notice,
inside of our application,
is we're not really ever resetting
these error messages though.
We, whenever we get an error message,
and we set it on our AUTH reducer,
we never actually clear the error message out.
So one way for us to kind of address that,
kind of oddity,
is if we go back over to our error AUTH reducer,
we'll say that if a user successfully authenticates
or logs out,
we should really clear any outstanding errors.
'Cause we're only really showing errors when
a user fails to sign in or sign up right now.
So whenever a user successfully signs in,
we can just reset this error
piece of state right here
to empty string, which means,
hey they don't really have an error at this point in time.
Don't worry about it.
Let's give this a shot out real quick in the browser.
I'm gonna go back to sign up.
I'm gonna create another account that's already been in use.
I'm gonna click sign up.
Okay. And then I'll make my email unique.
I'll sign up again
and we got the redirect to feature.
And you'll also notice that the error message went away.
Which is definitely the behavior that we would expect here.
Keep in mind that when a user successfully signs in
we don't really expect them to immediately come back
to the sign up or sign in forms.
But definitely I can imagine in the future
perhaps some interesting series of clicks
in which a user gets an error message here
then somehow navigates back to the form
and still sees the error message there from
when they had initially tried to sign in or sign up.
Which is really unexpected behavior.
So this is a little bit more predictable
probably what the user expects.
So our application is looking fantastic now.
I think one of the last things we need to do
is actually implement this feature route right here.
So at up to this point in time
we've been using this kind of dummy route where
feature has never been actually declared.
Let's fix it up.
So this feature actually maps to a usable route.
Let's take care of that inside the next section.