In the last section we started working on fenceposts and users and we've now got a better idea of how
we can call an action creator from an action creator and still kind of wait for the code inside of the
interaction creator to be completed.
So now we're going to start to move on our next step is to make sure that once we have called fecche
posts and waited for that action career to do its entire thing we then want to somehow get that list
of posts.
And there's a very easy way that we can do this.
Remember the second argument that redux thunk calls our inner functions with for all these action creators.
The second argument in addition to dispatch is the get States arguments that get state function is the
function that exists on the redux store.
That gives us access to all the data inside of redux.
So what we're going to do here is get access to that second argument of get state.
So now inside of this action creator after we wait for all these posts to be fetched and processed by
the reducer we can then call get States and reference the posts property and that should have all of
the posts that we just loaded up and caught inside of our reducer.
Let's very quickly test that out.
I'm going to take that gets gateposts and I will replace it inside this console log like so then I'm
going to remove the first console log.
All right so now everything works as expected.
We should load up our application see a brief little pause as we are fetching or let's suppose and then
we should see a log of all the posts we have fetched.
All right so I get to save this and we'll flip back over and sure enough I see the big con. right here
with all the folks that we have fetched and it's got all the typical ones inside there OK that looks
good.
So now the next thing we need to do is iterate through this list of posts find a unique user IDs and
then fetch a user for each one.
All right to do that we're going to make use of that load ash library that we imported at the top to
do that memoization step load ash is going to make working with this list of posts and pulling out the
user IDs and finding just the unique ones pretty easy and straightforward.
So let me show you how we're going to do that.
First off we're going to call get state.
We're going to reference the post property search number.
That is an array.
We're then going to use load ashes version of the map function to remember map is a function on all
javascript raise load ash has its own version of map that has a couple of nice little features inside
of it.
So I didn't say underscore map and I'll pass in those posts as the first argument.
Now we want to pull off just the user id property from all those posts and find just the unique user
IDs.
So to get just the user ID out of each one of these I'm going to put a second argument inside of here
a string of user id like so.
So again that's going to go through all of our different posts and pull off just that user id property.
So we'll then have as a result of this entire expression an array of all of the different user IDs it's
going to be 100 long because we have 100 posts so we now need to go through it and find just that unique
user IDs to do so we can also use load ASH for that.
Yet like I said hello ash is very useful you can use it for a lot of things.
So to find just the unique user IDs I'll call underscore dot you and IQ likes so short for unique so
unique is going to return an array with just the unique user IDs so will assign that to a variable right
here called user IDs.
And just to make sure that we're going down the right path here I'll cancel that out and we'll run this
really quickly inside of our browser.
All right so I'll flip back over and I'll see my counsel right here.
I have one two three four five six seven eight nine ten.
And again I've got that extra little idea inside there.
You are probably not going to see that whatsoever.
This is like a temporary little issue with the some placeholder API.
More importantly I see the correct list of ideas inside of here.
It's now the last thing we do is iterate over that list of IDs and for every ID we need to call our
fecche user action creator in the same way that we called our action creator appear.
So I will say user IDs for each and then for each ID we are going to call fetch user We're going to
pass in that I.D. and then we're going to dispatch the results of it like so.
All right.
This time around we do not have to put the away keyword inside of here.
The reason that we don't have to put a weight in front of dispatch this time around is that you and
I do not care at all about waiting for each user to be fetch inside a fetch Posten users.
It doesn't matter to us.
We just wanted to wait and make sure that we loaded up the list of posts and then once we got the posts
all we wanted to do was initiate it request to go and fetch the individual users.
But we don't have any other logic inside of here that we need to run after we fetch those users.
So we don't have to put any other awake humored in a wait for each user to fetch.
Not a requirement this time around.
If we had some other resource we wanted to fetch inside of here then we could use the Awake keyword
up there and then down here like get access to our list of users with get state DOT users and then like
print those out or do whatever you want to do with them.
Now one thing I do want to mention very quickly is that the syncopate syntax does not work with a for
each statement.
So if you did want to kind of a wait for each user to be fetched we'd have to adjust this code a little
bit just so you know how to do that.
I just I'm sorry I feel compelled to tell you how to do that.
I think at the top of my head I'm pretty sure we could do something like user IDs dot map or every ID
we could dispatch fetch user with the ID can return an array of promises.
Yes I think so.
I think we could combine that all together promised.
All like so and then like probably chain on like a van or put on an a wait.
Were getting really off topic here.
I just wanted you to have a quick example of how you might do that on our side off top of my head but
thats the path that youd want to go towards again anyways.
This should work out just fine right here.
So we're not going to loop over all the different user IDs.
We will call the appropriate action creator when we call that thing will then dispatch it.
That should make sure that our inner function inside the section create right here gets called by redux
think its going to make sure that we fetch that user ID and then dispatch the appropriate action.
And most importantly we're only doing that one time for each unique user ID.
So without further ado let's save this right here.
We'll flip back over and we'll test it out really quickly.
I'm going to flip back over and I still see that I get all my users on here.
If you look at your network request you will notice that we're still making all those duplicate requests.
That's totally fine.
The reason that you're seeing all these duplications is because our user header component is still attempting
to fetch its own data whenever it gets rendered on the screen.
So to make sure that we don't get all these duplicate requests now because we have a single action creator
that fetches all of our data for us we would open up the user hetter action creator.
So here we are right here user hetter.
It attempts to fetch its own data.
So we don't want the user header to fetch its own data anymore.
So we can move that component did mount next.
We don't really need the fetch user action Creator in here at all.
So I would remove that action creator up you're at the top and then we could remove the action creator
list from the connect function down here as well.
Like so.
All right so now we can flip back over.
I still see my list of users loaded up but if I look at my request log I've only made the very bare
minimum number of requests we fetched users ID one all the way through 10 and that's it.
So like I said two possible ways of solving this over fetching issue.
Now when we look at this newly created action creator right here the logic inside of it is pretty darned
compact.
And I think that even though this load ash syntax might be a little bit off I think that eventually
you would be able to look at this thing and understand what was going on pretty easily.
In addition we still have fecche posts as an action creator and fetch user so we can still fetch a list
of posts somewhere else inside of our application if we want it to and we can still fetch an individual
user somewhere else if we wanted to as well.
Finally I think that this approach is a little bit more clear than the memoires approach because like
we said before you would really have to stare at this code for a little bit to understand what was really
going on with it.
All right.
So a quick pause right here.
When we come back the next section we're going to do just one tiny little refactor to fetch Posten users.
It is totally optional.
You don't have to do it if you want to.
I just want to show you an alternate way of making these couple little calls with load Aktion side of
your.
So quick break and I'll see you in just a minute.