In this video we're going to start thinking about putting together the user Hetter component to be precise.
We're not going to work on the component just yet.
Instead we're going to focus on making sure that we have loaded up the data that we need to show the
user header.
Now that might sound confusing.
So let me give you a quick reminder on how this API is structured.
All right.
Here's the documentation for the API we're using.
Remember it's that Jaison placeholder Dom Type-I Cocom.
I'm looking at the resources section.
At present we are loading up this list of posts into our application so our app is currently showing
a 100 different blog posts on the screen.
We can open up that in point and we can see all the data that our application is currently retrieving.
All right here we go.
So we have this list of blog post we have a body.
We have a title.
We have the ID of each blog post.
And then very important for what we are trying to do right now we have the ID of the user who made this
blog post.
So this post right here was made by the user with I-T one and the same thing at the next post and the
next post and so on.
Every ten posts inside of here has been made by a different user.
So if I scroll down 10 posts I'll see that I now move onto the next user the user with ID number two.
And then we can keep on going down down down down.
Eventually we'll see that we get to user with I-T 10.
So all of the blog posts that we have retrieved are made by user 1 2 3 4 5 6 7 8 9 or 10.
So to figure out the details about each of those users we are going to have to make an additional API
request if you go back over to this Resources section right here you'll see the users and point.
So we can open up that request and you'll see that this endpoint has 10 different users.
So user with 81 82 and all the way down to I-T 10 down here.
So essentially if we want to show the actual name of the author of that post inside this user Hetter
component for every blog post we are going to have to make a follow up request to the user's endpoint.
Get that list of users and that will tell us essentially who made which blog post and Lookout's and
other we understand the problem here.
I want to tell you there is kind of an easy way to do this and there is a hard way to do it.
So the first show you the easy way because unfortunately for us we're going to do it the hard way so
easy way first.
All right so a quick diagram.
I put this diagram together here just to make sure it's really clear how the list of posts related to
each user but I think you probably understand that relationship so we'll just get that diagram.
OK so we know that we have the entire list of posts and we know that that users endpoint will return
us every user that exists inside of this kind of little mini application.
In other words if we make a request to posts and a second request to the user's endpoint we're going
to have without a doubt all of the application or all seem to all the data that our application needs.
Now here's the problem that's like way too easy.
This is a little sample application to help you learn things.
Nonetheless just getting that entire list of users from the get go is just entirely too easy.
Let me tell you why that's too easy.
I want you to think about a real blogging application like say medium dotcom if you've ever been over
there medium Dotcom has like millions of blog posts.
Millions of users if they want to show a list of blog posts along with their authors to the user or
to a user as we are doing right now the medium people you know the engineers are not going to send your
browser a list of like a million blog posts and a million users.
Instead they're going to send you like 10 blog posts to show on the screen or something like that.
And then you'll have to make a follow up request for each of those individual users.
So if we just made the request for all the users that we would ever need it's just too easy and it's
not realistic.
That is not how you're going to see things done in a real application.
So instead we're going to do things kind of like a hard way.
All right.
Just a little bit more challenging.
If you go back over to the documentation over here under the resources section you can see there is
routes right here.
So take a look at the second route.
What this is essentially telling us is that we can make requests to get one individual record at a time
as opposed to these big gigantic lists of records that we've been taking a look at.
So for example if I wanted to only get the user with I.T. one I could change the you are you are l appear
from slash users to users slash 1.
So that means as you might guess give me the user with the ID of one.
And so when I go there I see just the first user on the screen and I can do user at 32 and so on all
the way up to user ID 10 like so.
So with that in mind here's the flow that you and I are going to go through.
All right.
So inside of application everything is going to start off with us fetching that list appose.
So we're going to make an API request.
And then after some period of time indicated by this little arrow right here we're going to get a response.
We're going to return that data from producer.
All that stuff and then eventually we're going to show our lists opposed to the user inside that post
list component.
Now inside of that render list method that we have inside there we're going to create a separate instance
of the user header component for every individual post.
In other words if we go back over to the render list method right here this map function right here
or the inner function I should say is going to be executed a hundred times because we have a hundred
different posts.
So somewhere inside if you're like let's say right here we're going to place our user Hetter component
and we're going to give it a prop of something like user ID and inside of you will put whatever this
particular user's ideas for this particular blog post be it like one or two or three or four or ten
whatever it is.
And so we're going to create a bunch of instances of the user header component and each one is going
to know exactly what Id user ID needs to show on the screen.
Now I'm going to clean this code up I just want to give you a quick example.
So then inside of the user header component we're going to add a call to a new action creator that's
going to attempt to fetch just the individual user that that instance of the user header needs.
So we're going to end up with a bunch of separate requests for each individual user.
So this would be like fetch a user id one.
This would be like ID too and ID 3 and so on and so we're going to make 10 separate requests.
In theory one for each user will get each user return it back to our application somehow process that
through a reducer and somehow get each relevant user into each instance of the user Hetter component.
All right.
So thats the idea essentially the idea here just to sum up is that if we just fetch the entire list
of users that is too easy and the real world does not work like that youre not going to get this like
nice and point this is going to give you a list of every record that you need in the real world instead.
Its way more common to do some initial request to get like a list of records and then you have to make
a bunch of individual follow up requests to get more information about each of the original records.
And so that's that's is exactly what we want to do.
We want to get the big list and then make some smaller requests to follow up on it and get just the
information we need.
Okay.
So along the way we're going to see a lot of fun.
We're going to encounter one or two kind of catastrophic problems but hey that's where the learning
actually kicks in.
So anyway let's take a quick pause right here and we're going to start putting all the solutions together
in the next video.