In the last couple of sections we've really gone in headfirst of three blocks.
So I just want to take a quick pause and review how our app is currently working.
This is a pretty complicated diagram of exactly what's happening inside our application right now.
Let's break this down and walk through it step by step.
First when our app first boots up read X creates a new store right with that create store call using
the library's reducer.
The instant the store is created it runs this reducer one time.
So we get a piece of state called libraries which is an array containing a list of objects.
The reducer itself when it runs returns that array of objects and each object represents one library
that we eventually want to show up on our screen next after we create the store we pass it to the provider
as a prop where it's going to sit for the rest of the lifespan of our application.
The provider is a re-act component that ad that aids in communication between react and redux.
Next the app component is rendered to the screen which in turn renders the library list component the
instant that the library lists component is about to render are about to appear on the screen.
The Connect function which we just added in that connect help right here boots up and it says OK time
for me to do my thing.
The component I'm wrapping is about to render the connect function then it reaches back up to the provider
and says hey please give me access to whatever your current state is just just let me know your status.
The provider gives up the state that is contained within the store and then the connect tag pumps it
down into the library list.
After filtering through Mount St. to process.
OK.
So again let me just say a lot of steps right there.
Just break that down one more time.
When the Kinect helper first boots up it says oh the library list is about to render that connect helper
goes up to the provider says Can I have access to state.
The provider says Sure.
Here you go.
They connect helper calls map state to prop's without application state and then whatever object gets
returned will show up as props down into library list down here.
So the last step there is really key as well.
The map state to prop's function runs and it returns an object that objects like whatever it contains
whatever properties whatever values whatever data is then passed as props to the library list.
And that was the last step that we just verified inside of here.
Right we can't log this up props and we saw that it contained this object right here an object with
the key of libraries and a value of the libraries that existed inside of our state.
One thing I want to point out really quick is that you know again the term libraries is floating around
a lot right here.
This object right here that we returned when it showed up as props to our component.
It had the key of libraries.
It did not.
This right here can be absolutely anything that we want.
So it can be libraries.
It can be data.
It can mutate data to show whatever we want it to be.
It does not necessarily have to be libraries just because the piece of state that we want to reference
is state libraries.
I just chose to call it libraries because that is you know a very reasonable name for the problem.
On the other hand on our state object we have a very distinct property called libraries.
So I could I could not say of course right here like state idea because our state object does not have
a data property after very specifically say state libraries.
I guess that's pretty much where we are at.
Inside of our application right now I feel like there might be a confusing or item or two in this process
so I want to provide just a little bit of clarity on them.
First just to review you know exactly what I just mentioned about the libraries.
And second the second interesting piece I want to draw your attention to here is that our douceur had
produced some amount of state insider app even though we did not dispatch an action right.
So when are out first booted up and we cancel logged our state inside of that stage props and then we
later Konst logged it inside of our function right here.
This library's piece of state that came from our reduce or our library reducer over here already had
some data inside of it.
So when our redux application first boots up it will automatically run all the registered reducers to
keep cumulate some amount of initial state.
So we always have to design or inducers assuming that they would be called like over and over and over
again and at random points at time.
So thats why that whole type system that we saw earlier is so important the reducer needs to only change
its data whenever it sees an action with a type that it cares about.
In addition we need to make sure that we respond to the application first booting up correctly.
So when are out first boots up and it runs all the reducers one time we have to make sure that we return
some amount of initial state in this case here because we are just returning a very static list of data.
You know just this the Saray that is hard coded into our application.
It wasn't quite as big a deal.
But when we go back and implement the selection reducer it's something that we're going to need to think
about a little bit but we'll get there.
OK.
I hope this is a good breather to review our app is working right now.
Let's continue on the next section by working a little bit more on the library list component