In the last video we got our application working.
But there's one quick little improvement.
I want to make to our user Hetter a component.
Now this is a very small thing and it's going to appear really small in this case but it's something
that over time as you start to work on more complicated applications is going to become more and more
useful.
All right so let me show you what it is inside of our user head or component.
We are passing this thing a collection of different props.
Right now this thing gets access to the user ID and it also gets access to the entire list of users.
Now I want to point out something here really quickly.
The user Hetrick component is not really well-suited to take the entire array of users.
That might sound like a really weird thing to say but essentially the entire purpose of the user Hetter
component is to show one singular user on the screen.
It only has to show one user but we're giving it way more data than it ever needs we are giving it the
entire list of users.
And so to make this component by itself like just this class right here a little bit more reusable I
think that it would be a lot better if we could figure out some way to pass it.
Just the user that it cares about like maybe the ID that it cares about and the user that it cares about
but definitely not the big array.
So to do so there's a couple of different approaches we could take we could either get our entire list
of users inside of Post's list and then every single time that we render the user had a right year we
could go through that find logic and attempt to just pass in the user that we care about as opposed
to this user ID.
But I want to show you one other approach that we could take.
Back inside of my user head or component I'm going to go down to the map state to prop's function.
All right mount stage props right here.
Now you might notice that this map state to prop's function seems just like a little bit unnecessary.
Right.
Like every time we want to pull some data out of a component we have to define this really repetitive
function and then have to build up this object right here.
That gets some data out of our store.
Another way that would have been really nice to pull data out did the redux store then have to define
this whole function.
You can't do this to be clear.
You can't do this what I'm about to show you is not valid but it would have been nice if we could just
like pass in a string of something like.
Users like so and then just say that connect should understand that we want to pull the user's property
off the state object and pass it into our component as a prop called users.
Right.
That would have been kind of cool if we could have just done that but instead we have to go through
this really long definition of map state to prop's So it turns out that there's actually kind of a reason
for that.
The reason that we defined map states right here is so that we can do kind of like these pre calculations
on values that are coming into our phone as props and our redux state.
So rather than passing in like a ton of data to our component and relying upon the component to figure
out how to find the user that we care about we could instead extract all that logic to the map state
to prop's function.
So rather than going through this find operation inside the components self right that logic out inside
of map state to.
Now like I said that probably sounds like a very very small distinction.
You know I just told you two seconds ago.
Yeah you know it be nice to make this component more usable and it would be more reusable if we did
not have to pass that the entire list of users.
But then as the solution.
I'm saying that we're basically just going to relocate that logic to a couple lines down inside this
file.
So it might sound like that's no increase in re-usability at all.
Well let me tell you why this kind of technically is an increase in reusability.
It turns out that in some applications like some professional applications some engineers decide to
define this map state to proper function and this stuff right here inside of a separate file.
So you might have one file that has mapped state to props and the initial connect set up right here
and then in a different file you will define the component by itself.
The advantage to that is that you will have a component that can be used on its own without having to
reach into the redux store by going through all this work right here.
But then if you want to you can also very easily create a version of that component that will reach
into the redux store and get all of its own data.
In addition if you ever have another component that needs to get access to say just one particular user
given only a user ID we could easily write map state to props and this connect stuff into a separate
file and then reuse it in multiple components inside of our application.
So like I said it probably doesn't seem like this is going to be any increase in reusability of our
component but in the long run in some applications you're going to find that this is kind of a common
pattern to extract a lot of logic into map stage props.
OK.
So enough talking.
I think you probably get the idea.
So essentially rather than finding the appropriate user inside of our component we want to find the
appropriate user inside of map stage props.
So to do so I'm going to remove this fine statement right here entirely.
We're going to replace it in just a second and we're going to instead place the find statement inside
of Mount St. to.
So I will say St..
Users find and then for every user inside there I want to look at the user id and compare it to oh wait
oh that's a little bit of an issue.
Right here we want to find a user ID that is equal to this component's prop of user ID but that Propp
is only available inside that component.
We can't get access to it inside a map stage props or can we.
Well it turns out we can.
So maps to prop's does not only get cold with our state object out of our redux store as an argument
it actually gets a second argument as well that is referred to as own props this own props object right
here is a copy not actually a copy is a reference to the props that are about to be sent into this component
right here.
So if we ever want to do some of these like pre calculation steps so that we don't have to pass in a
ton of data directly to the components we can reference the props that are about to go into the components
on this object right here.
And then we get our redux state on the first argument.
So essentially we're going to compare user ID with own props dots user id like so and that's pretty
much it.
Well actually just a little bit more that's going to find the appropriate user.
We don't really want to assign that to a property called users anymore.
We probably want to assign that to a property called user.
So we'll update that.
And then finally inside my render method we no longer have access to the Propst users value.
Instead it's simply this stop Propst users Cingular because now we are only passing on the one user
that we care about to our components.
So instead of my render method I'm going to do structure off just that user from my prop's object.
And so now we can check to see if that user exists.
If they don't we'll return NULL and show nothing on the screen.
But if they do we'll show their name inside that div OK.
So again the entire idea here is that we can extract anything that is going to do some computation on
our state our redux States and the prop's coming into our component to the map states prop's function.
And that's really what map state to props is for.
All right so let's save this and then we'll test it out really quickly and just make sure that everything
still works and it looks like yes it does.
I still see all my authors on here.
OK.
So that's a good refactor.
Now I'll take a quick pause right here.
When we come back the next section.
Remember I'd said very mysteriously that there's still a little bit of a problem inside of her.
So let's take a quick pause come back the next video and I'll show you exactly what that problem is.