Continue with our authentication wire up we need to also make sure that when we log in a user if the
initial requests to authenticate them fails we want to make sure that we also attempt to create an account
for the user as well.
So we're going to follow the same methodology as in our authentication app.
If an email and password combination fails we assume that the user needs a new account.
So we will attempt to create the new account.
So our start is going to be the same as the the we handled authentication previously.
If we hit that then case that means that the user successfully logged in if the authentication with
email and password fails.
That means we're going hit a catch case.
So we had a catch case in here and whenever we had this catch case we're going to do a couple of different
things.
First off we're going to call firebase dot off God creates user with e-mail and password and it'll pass
in the email and password that were entered.
And then after that we'll get back a user model and inside of there.
We will also dispatch the logging user success action.
So type log in user success with a payload of user.
All right.
Now I want to point out to you.
She has this is some really nasty looking code here.
We're only really doing you know two things more or less like sign in the user with the email and password.
Failing that try to create a new account.
But this is one nasty block of code right here.
And I would not be surprised if I have a hidden typo somewhere in here.
This is where yes Lent is definitely very helpful.
So clearly very nasty that we're working with here.
This is the absolute downside of redux.
So it can really add to or really contribute to some kind of Pyramid's of doom as you see like this
right here.
I mean we're using promises which cleans up things a little bit but still at it's kind of nasty.
The best solution that we can come up to handle this is to make a couple of helper functions for processing
the callbacks that we have in here specifically the success cases.
So you can see that if we successfully sign in with email and password or if we successfully create
a user in both cases we are dispatching an identical action.
So I would suggest that we create a new function called log in user success.
It will take the dispatch method and automatically dispatch our success.
Action for us.
So essentially we're going to make a helper method to clean up this log in user action creator.
Let's see what it looks like.
You'll notice that I'm not going to export this new method because I really do not intend to call it
directly from anywhere else inside my application.
It's really just for use to support the log in user action creator well-define log in users success.
It will be called directly with a dispatch method and the user that just signed in.
And then inside of here we will dispatch our log in user success action.
So all of a type of log in users success in a tight or excuse me a payload of the user.
So now we can clean up our code just a little bit inside of the logon user action creator.
First off I'm going to delete both the dispatch statements so delete dispatch number one and then delete
dispatch number two.
Now I've got two vans.
Each of them just have kind of dangling federal function with the user as an argument.
Then inside of both these I would call log in users success and I need to pass along the dispatch method
so that it can actually do a dispatch and also the user.
So log in user success with the user.
So again one more time just because I want to make sure that we get the right code on the screen here
I have two events both of them are identical and they should both take a user and call log and use their
success with dispatch and the user.
So this is a little bit better but definitely two more things here we need to make sure that we bubble
up an error message to handle the case in which the user just like puts in the wrong credentials.
And we also need to make sure that we send across an action when the action creator is first called.
So we noticed start up the spinner right.
We need to make sure that we notice start up the spinner when the action crater's first called So let's
start with the handling the fail case first.
And I think that we should also put the fey handling the fail inside of a helper method as well because
it's really going to clean up the file a little bit.
So I'm going to make another helper method helper function called log in user fail.
This will be called with the dispatch method and all it has to do is dispatch an action of type log
in user fail.
Now we don't have that type yet.
So let's go create it.
I'm going to go up to the top of this file and I'm going to import log in user fail at the top.
I wanted to make sure that our type file has that as well.
So I'm going to find my type's file inside the actions directory and I'll add an export Konst log in
user fail
OK.
So everything that we're doing this section again it's all about making this log in user action creator.
Much more robust to handle the spin or handle the error messages handle is success.
So we have now added in code to handle success of signing with the email and password.
Success of creating a new account both those were handled by the log in users access method and then
we also just created log in user fail which dispatches an action of type log and user failed.
So we will definitely want to make sure that we eventually hop over to our reducer as well and pick
up on this you know pick up on the log in user fail message right here.
So doesn't want to take that as well.
The last thing we have to do is make sure that we actually call log in use or fail at some point.
So we're only going to fail the user out of this flow after we have both tried to sign with email and
password and create a new user with the email and password.
So after we attempt to create a user with the email and password I'm going to add on a catch case notice
that I'm going to take off the semi-clean on the van here and take it off.
And if that fails I want to catch and directly call log in user fail with the dispatch method and then
nothing will be responsible for dispatching the fail type.
OK.
So again a really nasty chunk of code right here.
This is definitely where redux thung starts to get you know a little bit painful.
Let's continue on the next section and make sure that we are handling starting a spinner showing error
messages and all that kind of good stuff inside of our producer