Unless section and we were able to successfully test out our Fettes user action creator we're now going
to come back to this action creator and do a little bit of a refactor to it.
At present it's still making use of a promise that is being returned by Axel's get remember anytime
we make a request always returns promise.
We can get a little notification of when that request has been resolved by changing on the dot then.
So at present we're saying after this request has been resolved and we get a response back dispatch
an action containing that response.
So payload of rest right here.
Now the code that we have on the screen at present definitely works without a doubt.
But when you really look at this thing man it is awfully ugly isn't it.
Like that thing is just ugly.
There's just so many lines to it.
It's really tough to look at and get a very succinct understanding or a very quick understanding of
what's going on here.
So we're going to really factor this action creator to use the async await syntax instead.
And simultaneously we're also going to kind of use aero functions in a slightly tricky way.
That's going to also kind of condense down this extra function here.
Right.
So let's get to it.
We're going to do the three factor one step at a time one step at a time.
The first thing we're going to do is we're going to look at the outside aero function.
So the arrow function that is being assigned to the fecche user variable.
So here's the arrow function.
We've got the argument list we've got the arrow and then we've got the inner curly braces inside the
curly braces.
We have a single javascript expression which is to define a function.
So we have got this single expression.
Soon as we define it we then return it.
So the first little refactor we're going to do we're going to exploit a little rule that are that exists
around aero functions with an arrow function.
If you have curly braces and the return statement and the return statement is being used with a single
expression.
So in other words there's like no other code inside if you're like say one plus one equals the variable
two.
So if we had this this would be two separate expressions.
But right now we just have one right.
So we'll just have one expression.
You can remove the curly braces and the return keyword like so.
So this code right here completely equivalent to what we just have.
We still have an arrow function that automatically returns the function that we define inside of here.
So just to prove to you that it still works I'm going to save this code right you're going to save this
file and it will go test it inside the browser again.
So I will go back over or refresh and yes everything still works over here.
OK.
So refactor one good.
Now I'm going to take this function key word that we defined and rather than define a function keyword
we're going to return an arrow function instead.
OK so this is really just purely stylistic no difference between using a function keyword or an arrow
function for this inner one right here.
So rather than function cuarto over the Late thought and then on the other side of the argument list
I'll put down my arrow like so.
So now when I save this well I said I want to save it just yet because my do pretty or kicks in and
refactor everything.
But if you just look at what I have on the screen right now you'll see that I've got the argument list
and then the arrow function body.
Now when we just have a single argument we don't need the dispatch or we don't need the parentheses
around that argument.
So I'm not going to remove the parentheses and then when you look at what I have on the screen now.
Well I can really just move this separate function declaration up to the same line as the previous one.
There's no reason I can't.
So I'm going to take this.
Put it on the line right above it and then do to just what I have on the screen right here.
So I to save this and I get tested inside the browser again just to prove to you that this still works.
So I'm going to go back over a refresh of the page and yet still have the action.
So everything is still working.
Now at this point I want to say yes this code looks a little bit strange but it still is 100 percent
valid javascript.
Now let's do the last refactor here.
Last factor we still are making use of the then statement in here.
So we're still using promises rather than using then and then having this like extra function in here.
I want to use the ace async await syntax inside of this arrow function instead.
So the last step to the key factor we're going to find the function that is currently generating some
async logic or generating a promise will market as being async.
We will then replace the actual promise with the weight keyword and then finish the rest of the refactor
just like we did previously when we first learned about a single weight.
So the function that contains a promise is this one right here.
So right before the argument list I'm going to place the async keyword so I'll say async dispatch like
so.
So async dispatch I know this looks very strange to have the two words in a row.
It might look a little bit more straightforward if I put the parentheses on like so but really no need
for it.
Same thing.
Now inside of the actual body I'm going to find all the different promises and mark them with the a
weight key word.
It's going to first condense this thing down to a single line and then say a weight axial start get
and then I'm going to replace this entire Then statement down here and assign whatever the actual request
gets resolved with with an assignment to a variable.
So say Konst rez equals awaits.
Actually Alstyne gets.
And then the last step I can remove the entire dot then statement and only keep around the actual body
of the function which is the dispatch statement.
So I would move the entire dot then I'll make sure I clean up the extra parentheses on the right hand
side too like so.
And in the very last thing I make sure I indent it correctly and at the end of the day we are left with
just this right here in Seoul save it.
Go back over to the browser.
There's a refresh.
And yes everything is still working the exact same way it was before.
So pretty distinct change right.
Like that's quite the factor.
So to be 100 percent clear everything we're looking at right here 100 percent equivalent to what we
had before.
Like all of this same thing we are still returning a function that makes a request and then only after
the request is completed do we dispatch an action.
Just using a highly modified bit of syntax that really just cleans up the function the entire action
creator.
So I think that personally this is a lot easier to read if you're sitting there thinking Stephen you're
crazy.
This is definitely like.
Absolutely not.
Easier to read.
Well you know what you are entitled to your opinion and I don't disagree with you.
The very first time you look at this compacted syntax you're going to think to yourself This looks weird.
I'm not familiar with it.
It makes no sense to me so I don't want to use it at all.
But I'll tell you what I encourage you to use it.
Just give it a shot and after a little bit of time of working with this compact syntax you will get
used to it.
So if it looks weird it's just because you haven't seen it before.
I encourage you to work with it a little bit and as soon as you do you're going to have a much better
sense of what's going on here.
OK.
Now I want to say just one last like possible refactor we could go like really overboard.
So I'm going to like make a duplicate here and then do a quick refactor just to show you how deep we
can really go.
So I don't really need to assign the response Torez I could just take the entire request and then assign
it to the payload like that right there.
If I do this I did no longer need the actual semi-colon at the end.
I don't need the I'm not returning anything from here and I only have a single expression so I can also
delete the overall curly braces and then when I see that we get a little bit of an error message I probably
made a little typo somewhere here here but you know we'll just let that go.
Anyways the point I'm trying to make is that you can really take this and still like mess around with
it a lot more than we have already.
But you really don't have to.
I encourage you to just say like this is a good starting point right here.
That's all I'm really trying to say.
OK.
So I think that this is enough for all the other action creators were going to write and this course
we're going to end up with something that looks pretty similar to this right here.
So we will definitely get the opportunity to write many more action creators that look just like this.
So with that mind let's take a quick break.
We'll come back to the next section and continue with our application.