Our application now has two pieces of state that e-mail and the password.
So in theory once a user enters these we're ready to actually sign them into our application.
So the next thing we need to work on is figuring out how do we actually sign in a user right.
Well as we figure out in the past we use firebase to authenticate our user.
But thinking about authentication I just kind of thinking about it in general I'm starting to think
that maybe our author reducer is going to need to maintain a couple of their properties in here beyond
just email and password.
So let's check out a mock up on the left hand side is what our state currently is like what it looks
like when we run our application we have just e-mail and password and nothing else.
That's it.
What I'm going to propose for our application state.
We're going to propose our author douceur comes in to responsibility for is a loading flag an error
message and a user model.
So let's talk about each of these really quick where we know what the e-mail password are.
Those are just the strings that the user is entering.
How about the loading flag here.
This Ludi flag is to me just like the one we previously had.
It's going to be a boolean either true or false.
And it's just going to record whether or not we are currently trying to authenticate the user.
So the purpose of loading right here is just so we can show spin.
That's it.
Nothing crazy.
The air flag again is just is a string.
It's going to record whether or not there is a error in authentication.
So just the strings can say something like authentication failed or whatever.
We feel like getting a message to now the last one is a little bit more interesting user.
So user here is going to be the user model that is supplied by firebase.
So we'll learn a lot more about this in just a little bit.
For right now just take my word for it that this user property is going to be an object that tells us
stuff like here's what the currently signed in user's username and ideas.
So just a short description is an object as a short description of our user who is signed in.
So all in all I am suggesting that we expand the properties of a producer Orsini the properties that
reduce or mix by adding in these last three on here.
That is what I'm suggesting that we do so of course because we want to update our application state.
We're going to need to toss in some action creators and types and all that other good stuff to manage
these properties right so we can like actually change the loading flag an error flag in the user like
all that kind of good stuff.
So now that we know what the properties we want to maintain Are we can start to think about when we
want to update each of them.
OK.
Want to think about when we're going to update each of those flags.
So email and password.
We've already done and those two are kind of obvious right.
Whenever user types something in the email field I want to update my email whenever the user types something
the password field I want to update my password password piece of state.
But these new three down here.
Well they're a little bit different weren't they.
They're a little bit different.
The loading flag will probably start off as something like null because or false because by default
when the user first starts the application up.
Yeah you know we're not actually loading anything just yet.
So probably start to false or whatever.
But once an authentic quake authentication request starts we're going to flip it over to true and then
very importantly this is like the real world and trying to hammer in here what I'm trying to get at
is when the request is complete when like the signing request is complete we're going to flip it back
to false.
OK.
So when the request is complete I want to change this value of this piece of state right here.
Same thing with the error message.
By default I mean empty string.
But when the error or when the authentication request is complete I want to get an error message and
maybe you know update this to show the user an error message.
And the same with the third one here as well.
By default it might be like nold to say no user is signed in right now.
But when the authentication request is complete I want to put the user model in there as this property
so the common the common theme here the goal with these last three poverty's is that after a user or
after we make a request to the firebase server we want to update our application state.
OK.
That's the goal.
But no problem with that.
Right.
Like we know how to update our application state.
We make an action Creator and we return in action.
And our end user updates something like Whatever.
What's the big deal here.
Well maybe it's not so simple.
I want to point out some little little issue here.
So first just to make sure everything is crystal clear about this kind of set up this prep I'm trying
to do here.
I want to just be very clear very direct with you whenever user presses out logon button right there
when they press it.
We're going to call something like a log in user action creator with email and password and that creator
is going to make a request to sign that user and I like to log them in.
Now that were the again the part them trying to make real quick crystal clear right here is that this
action creator must by definition be making an Ajax request.
Right.
So it's going to make an Ajax request.
And until that request succeeds or fails until it completes.
We don't really know what action we want to return from that action creator and that's what I'm really
trying to get here.
So I'm really trying to get at by default whenever we like as all the acting creators we've proved so
far behave when we call an action creator.
It runs.
We return in action.
Boom.
Here's the Ox.
We call it runs it get the action back toss off to the producer.
Instantaneous no delay whatsoever.
But with this new idea this new request that I want to make things behave a little bit differently when
we call the action Creator it runs we make a request to firebase and say wait a minute we don't actually
have anything to return yet.
Remember Ajax requests are asynchronous.
So inside that action creator we have no value no action return.
Nothing to say like hey here's the user the user is going to come in a minute.
Like just hold on don't actually return to the action yet like we don't know what it is yet.
Only at some time in the future when the request is complete.
Can we actually return an action that is when trying to get out here.
So when we have action creators that make Ajax requests things behave a little bit differently and our
existing pattern of call the action create or in turn action starts to break down because when we make
an Ajax request we don't immediately have anything to return from this function.
And remember in javascript there is no such thing as like sleep or weight or anything like that.
When this action creator runs it's going to execute the coding side of it and then immediately return.
And there is nothing you can do to stop that.
So there's no fancy way that we can somehow like say oh make Ajax request a write up here but don't
return anything just yet.
Like just give me a minute to like figure out what this value should be.
So clearly our existing pattern for action creators is not going to work when it comes to making Ajax
requests.
Clearly we need some new methodology here.
We need some new way of handling action crater's that's going to help us to make an Ajax request and
then at some point in the future maybe dispatching action to say loading is complete.
Here's the error message if there is one.
And here is the user.
If there is one OK so when I saw I'm just condenses all down to a single sentence give you the summary.
The big problem here is that we've been writing synchronous action creators that instant return in action
but we need to be to write an asynchronous action creator that will return an action at some point in
the future.
So of course this is not an original problem.
Like I didn't just stumble across this redux has our back on this one.
Let's discuss how we're going to solve this in the next section.