We've now set up our first component with re-act rather inside of our application.
So we're going to take a little bit of pause and move over to the redux side of things and get that
side of our application set up and architected.
So let's take a little bit of time to talk exactly about how we're going to set up the redux side of
our application.
We are going to do things just slightly differently when it comes to the design of our state objects
this time around.
And so in this section I wanted to explain why we're going to do things slightly differently.
Now let's first start off by taking a look at our API documentation for the Post's API that we're going
to make use of.
So we had previously said that whenever we fetch a list of posts we would expect to get back an array
of objects where each object represents one particular post every single post has an id property and
that is a completely unique property.
So it has an idea of one ID to two of three or whatever it might be Deyes want to remind you array of
posts each post has an ID.
OK.
So that reminder in place let's flip over to a diagram and I want to look at how we might design our
state object if we were following all similar conventions as we were in previous applications that we've
looked at in this course.
So this is how we might approach things if we were using identical approach to the previous applications
we're working on.
OK.
So we're not going to follow this approach I just want to that right now.
I just want to remind you about some aspects of taking an approach like this.
So if you following some of the rules and lessons we had learned in the previous applications we worked
on we might end up with say a post property and an active post property on our global state object.
So this is the state that is being produced by redux right here are posts property which would be presumably
produced by the post reducer would probably be an array and that array would contain a list of all the
different posts that we have inside of our application.
Then we would also have something like active post or selected post.
And that would be the object that we were looking at.
So the second property right here is really important when we start thinking about the show page inside
of our application the page we want to show the user just one particular post on the screen.
So just take Here's our post here's the post with I-85 presumably so you can imagine that when ever
a user goes to that page we would set this active poster property to be in the post with ID 5 if we
were going to this route right here.
So the reason that we're not going to use this kind of structure right here for our state object inside
this application is specifically to deal with one really interesting interaction between reactor outer
and redox when it comes to kind of the idea of a currently selected object.
OK.
So let's let's kind of drill down into this is where things are going to get a little bit crazy.
So do bear with me here for a little bit.
We really think about our application state and the URL of the application.
It's a really interesting thing because the you Arel that a user is visiting like this route up here
is really a very critical piece of application state.
Right.
Like user visits some different you are l.
We expect our application to update in some fashion.
We expect to see different components appear on the screen and that's something that we've been saying
about state all throughout this course.
Whenever state changes we really render our application.
And so how is the URL any different from another piece of state whenever the URL changes we want to
show some update we want a rerun or something we want to fetch some data.
And so when we really think about it the current route that a user is looking at is really another piece
of state inside of our application and most importantly for this show page right here.
When you really think about it the ID that is reflected inside of that route or this particular route
for showing the user or a particular post is really providing the exact same information as is being
provided by this active Post piece of state right here.
So really this active post thing is really a duplicate piece of state.
Its really this piece of soup's wrong way.
It's really the exact same thing as reflecting the post ID and the you are l.
So I'm going to suggest that since we are already reflecting the idea of the post that we're trying
to look at inside the RL Maybe we really don't need this active Post piece of state at all.
Who cares about it right.
We don't need to reflect the active post inside the url.
We can just take our big list of posts we can take the idea out of the URL and use those two pieces
of information to decide what posts we want to show on the screen.
So in other words whenever we render the post show component we can look at the URL we can look at our
list of posts and we can say hey find the post with ID 5 out of this list and show it on the screen
to the user.
OK so that's that's like Step 1 Step 1 in changing our state structure here.
So step one is to just understand why we really don't need that active Post piece of state.
So hopefully at this point in time you're still with me here.
Hopefully this makes sense in your thinking.
Okay yeah that sounds reasonable.
You are l does reflect the ID so we really don't need this extra extra piece of state in here because
we can manually calculate it by looking at our posts list and the u r l that a user is looking at at
any given time.
So again that's step 1.
So with that kind of configuration that change in mind I want to make just one more small change to
our application state and this additional change is going to be the final product or what the state
is going to look like inside of our application.
So we just may change number one.
I'm going to make one other small change and that will be the final product.
So let's look at a slide for that.
Okay.
So two small changes really one small change made to the diagram that we're just looking at.
So again we don't have the active piece of state anymore.
But this time around I'm saying that maybe it would make more sense to store our list of posts inside
of an object rather than an array.
So notice that inside of this object that I'm suggesting we use.
Now I'm saying that the key will be the idea of the post and then the value will be the post itself.
So you can see that I've got an object starting right here and closing over here.
It has an idea for and I'm going to suggest that maybe we use a key of four for that post because that's
the idea the post and then same thing for the next one down here.
We've got an ID and a queue of 12 ID of 12 right here.
And so the reason they are making this change right here is just to make it easier to find a particular
post.
Out of all the posts we've fetched so I want you to imagine for a second just imagine that we still
were using an array like this right here.
If we then wanted to find a particular post like the post ID for to show on the screen we would have
to write like a for loop or use the find the re helper to pick out a particular post from this array
of objects right here.
But we can do that Look-Up much more quickly if we store our posts in an object like so.
Because with this type of structure right here all of a sudden to find some particular post when we
get a new Olson to find our particular posts it might look something like state DOT pose and then we'll
access post ID something like that right there.
And that would return say you know this given post or that particular post.
So again the purpose of going from an array to an object like so is just to make this look up process
a little bit easier and involve a little bit less code.
And so to be 100 percent clear this post Id very well right here.
I'm imagining that we're kind of pulling that directly out of you or else so maybe we would look at
the URL we would pull five out of there and then we would use that five to look up against our object
containing all the different posts.
OK.
So at this point I've got to tell you introducing the idea of an object for holding properties or records
inside of redox is a very advanced concept.
And so this really is a very challenging refactor right here that I'm suggesting but I got to tell you
this is how we really do it in production this is how we really build large applications that scale
well.
So it is a little bit painful refactor as we go through this but you know it's definitely something
that we have to do out of necessity.
So with this knowledge in mind let's continue in the next section we're going to start working on our
action creator to fetch a list of posts and we're going to somehow turn the array of posts that we get
back from our API into this object that contains the post as well.
So let's take care of those challenges in the next section.