I'm all done generating my project.
So going to change into that new blog directory that was just generated then inside of here I'll start
up my code.
Editor I'm also going to install the react navigation package right away so I'll do npm install react
dash navigation.
Remember we've been using this package throughout this course to show different screens to our users
in this application we're going to work on we very definitely very clearly have many different screens
we want to show.
So I think we should wire up react navigation right away as usual if you see any warnings after doing
that installation.
Totally fine.
And then finally I'll do an NPM start and we'll get that browser window open running the React Native
package.
And here it is right here.
So as usual if you're on a physical device scan that QR code.
Otherwise if you're using an emulator or simulator you can hit those links on the side.
OK.
So I shall should see my application appear in my emulator and simulator very quickly.
So I'll just let that go ahead and do its thing.
OK.
So while everything is loading up honestly a couple of diagrams to just help you understand some big
things we have to think about inside this application.
So as we mentioned we're gonna have four different screens here listing blog post showing one creating
one and editing one all these different screens are going to be shown by the react navigation stack
navigator just as we've used on previous apps so we can kind of imagine that this is our component hierarchy.
We've got the stack navigator right here and it's going to decide what different screen we want to show
at any given point in time.
Notice that I kind of took an assumption here about what we're going to call our different screens maybe
index screens show create edit and so on.
Now there's a really big important thing that we need to think about inside this app and that is we're
inside of here are our list of blog posts going to exist.
In other words at some point time we probably need an array of objects to represent all the different
blog post that a user adds into our application.
So we need to think about where we're going to locate that state if we somehow follow the same pattern
as we've used on previous applications.
We might decide to just add in a state variable to our index screen and maybe that would be an array
of objects called like blog posts and then anytime they wanted to add edit delete whatever this list
of blog posts we could maybe somehow figure out some way to pass some callbacks around to these other
screens.
So maybe try to pass a callback over to show screen or create screen or edit.
That would allow them to try to make some change to some given blog post and send the updated blog post
back over to the index screen.
So this is maybe one way we could approach this but it's definitely not ideal.
This approach would very quickly introduce a ton of coupling between the different screens of our application
and if we wanted to ever add in some additional resource besides blog posts like maybe we also wanted
to manage images or comments or something like that.
This approach would be really confusing.
Really quickly so instead we're going to take a radically different approach.
We're going to instead introduce something called a provider component.
This provider component is going to essentially wrap our entire application including the stack navigator.
This will be a rat react component but it's not going to actually necessarily show anything on the screen.
Instead it's going to be responsible for managing all the data or more specifically all the different
blog posts inside of application.
So we're going to essentially centralize all of our data inside this one component right here.
Then if any component ever needs to get access to that data or if a child of one these screens like
let's say the blog list right here needs to get access some data we're going to essentially wire up
a system that's going to allow any screen or any child component to get direct access to the list of
blog posts inside of our blog post provider.
So we could kind of skip and not have to pass props between each these layers to get a list of blog
post down into this blog list component.
Instead we'll be able to get a crop year of like blog lists from our provider all the way down to the
blog list somewhat automatically.
We will also use this same kind of system to pass some callbacks from the blog post provider down into
the blog list that will allow maybe the blog lists to delete a post.
So also pass in something like delete post which would maybe be a callback function with the goal of
deleting some particular blog post so the entire idea here is understanding this pattern.
Now as a quick aside this idea here of kind of centralizing all of our data at some very root location
inside of application is referred to as global state management.
We're essentially trying to manage all of our state inside of one single location.
If you've ever heard of that library redux usually the redux library is used for functionality very
similar to this essentially identical but you and I are going to essentially rebuild redux more or less
kind of from scratch using just a couple of hooks and one or two features inside the react library.
So we're not going to be really going over redux very heavily inside this course which might be a really
big disappointment.
But to be honest you're going to essentially rebuild it more or less from scratch.
So you're going to get a very deep understanding of exactly how redux works by essentially re implementing
it.
And if you decide to learn it on your own it you're gonna have a pretty darn easy time doing it.
So that's pretty much it.
We're going to try to centralize all of our data in this very route component right here.
So let's take a quick pause.
When we come back the next video we're going to get started sending up our application and we're going
to create all these different screens and then wire them up to a stack navigator so quick pause and
let's get to it in the next video.