The last section we realize that there is going to be a little bit of issue with our piece of state.
There are some pieces stayed on there that we can only update after we make an asynchronous request.
We eventually came to the realisation that we've been writing action creators that are synchronous in
nature so we run them and they instantly return in action.
This does not work out for our kids though because we want to authenticate a user which is going to
take a request and then only after that request succeeds.
Do we have the information we need to actually return in action or dispatch an action as it were in
this section.
We're going to address this by first writing out our action creator with the authentication request
and then make some changes to it to ensure that it works in an asynchronous fashion.
So first we need to make an action creator that will attempt to log the user.
So just something that's going to say hey firebase log in this user with this email and password.
Now be clear the code that we're about to add will not work the way that we wanted to.
It is just a starting point.
We're going to kind of play around with it a little bit until it gets working.
So first first attempt is give me just that an attempt.
So inside my action creator file I'm going to make a new action creator say expert Konstam MICKOLUS
log in user with the very obvious purpose or job of authenticating user.
I expect it to be called with an email and password
and notice that I have the curly braces on here which means I expect this to be called with an object
that has an e-mail and a password property on it.
Next we're going to add some logic to handle our firebase log in.
First we will import firebase up at the top of the file.
So at the very very top I will import firebase from firebase and on down at the bottom inside our action
career that we just created.
We're going to create or to add in our authentication call.
So again for right now we're just going to attempt to sign a any user and not worry about creating a
new account or anything like that.
Just sign in the user so say firebase dot dot sign in.
You remember this long one right with email and password.
They're going to pass and email and password
again just to make sure everything here is crystal clear this call is going to make a request to firebase
the servers.
So the earliest time that we can get access to any response from it are like any.
And it says like hey everything worked out ok.
Is by adding in a then clause because this is a promise right here.
So we'll say then when you get back the user just go ahead and cancel log the user
so the then clause will be executed after the request is finished.
And it will be called with a user if one exists.
If we enter an account that does not exist for invalid credentials then we're not going to see anything
out of this promise right here because it's going to hit a ketch case and we're not handling that catch
on here right now.
OK.
So after all this big lead up after all this you know big deal how do we fix this issue with asynchronous
action creators.
How do we only dispatch action after we hit this then right here because this technically right here
is exactly when we would want to return an action to do this.
We are going to use a supporting library called redux Thuc.
So that is like the big solution here we're going to use redux thung to handle asynchronous action creators
redux.
Thunk is used to handle any type of asynchronous action Krater that we might need throughout our codebase.
So right now we're using it for firebase but it could be for any type of Ajax request or any long running
process that you could possibly imagine.
Redux thunked is a NPM module that we need to install and actually set up.
So we're going to go through that process now at the command line.
I'm going to install Reebok's thunked by running NPM install dash dash save redux dash.
Thank you and while that goes we're going to look at a quick little diagram.
It's going to help us understand what the Sing's doing for us.
What is redux really doing.
So first I want to go back and review a little bit.
Our default action create a rules so by default I mean like how they work right now.
Right like without redux tongkat all action creators are functions they must return in action and an
action is an object to the type property and optionally a payload as well.
So this is how actions behave right now are action creators behave right now.
So the whole point of re-ups thung is to allow us to bend these rules like that is really what it does
it allows us to bend the rules of action creators.
Here's how it bends the rules.
Once we install redux thunk we can either create an action creator which is a function and must return
action action must be an object or or like so here's the big Or here's the bending the rules part really
breaking them I guess.
But you know what I mean with redux thunk and stalled action creators are functions so no change there.
Action creators must return a function so that is the new part right here.
Instead of returning an action which is an object we can return a function from our action creator.
That function will then be called automatically for us with dispatch.
And that last part there that that dispatch this is the real magic part right here.
Dispatches the magic part.
If you think back to when we first went over redux inside the Jazz playgrounds tool we use storm dispatch
to dispatch or process an action or send it off to all of our different reducers.
So the whole magic behind redux thunk is that it allows us to bend the rules of action creators by allowing
us to return a function that gives us direct access to dispatch the dispatch method and that dispatch
method will allow us to return or excuse me to manually dispatch an action to all of our different reducers.
OK still again a lot of lecturing here.
Let's just verify that the install went successfully.
Yup.
Here's Reebok's thunk.
Let's take a quick break now and then come back and figure out how to use Reebok's thunk.
In practice