All right, so let's get familiar with the star project now, of course, since this is the bigger project,
I believe it's the biggest one in the course, there's more info that we need to cover as far as they
are now.
Start very simply with the public one.
Remember, we had the redirects and that was for an amplifier.
So the fly and react router would play nicely.
And I have covered that already before and of course, so I would just leave it at that.
Then we have it next to them now and here we really only care about the title.
So in this case it says comfy slot star.
So if you change this round, of course, the title will also change.
Now, as a side note, if you do want to get a favor, you just need to get it online and then replace
it, because at the moment, of course, we just have the react one.
So that should do it for the public.
Nothing really interesting over there.
Then we have a source, of course, this is where we'll do all of our work, essentially, and in here,
like I said, this is a much bigger project.
So essentially we have way more folders.
And also you'll notice that way, more files here as well.
Let's start very simply.
We have assets.
So this is where I keep the images that I will use in the project.
So here I have the logo, essentially the country slot and also two hero images.
Now, rest of the images, if we take a look at the project, are going to be coming from the API.
So I set up my own API where, of course, all the products have the images.
That's why when we talk about assets, we to talk about this logo here and these two images, that's
all we've got over there and we have components.
So, of course, these are all components that we'll use throughout the project.
Now, not only I set up the imports since I avoided to retyping the boilerplate.
And of course, I'll cover that in a second.
But you'll also have the styled component over here.
So don't freak out if you go through the components.
And then, of course, you can see the imports.
We should be already familiar with that, correct?
And then not only there's a boiler plate for the component, there's also some funny looking scissors.
Now this funny looking Jesus is styled component that I'm going to cover in the next videos just to
give you a general idea how it works.
But essentially, the idea is following where once we used style components, I don't have to jam all
my styles in the indexes.
Now, you will find some global styling here.
Norrish here we have some typography stuff and things like that.
But when it comes to individual components, we'll set up all our success over here.
And of course, I said I'll talk about it in greater detail.
Next video, but don't freak out.
This doesn't mean that I already prepared some functionality for, you know, because it just means
that I placed all my styling right away in the component.
And I'm going to cover that how it works a bit later.
So, again, if you visit any of these components, what you find there is just some boilerplate, just
some basic boilerplate, because, again, we have done this already quite a few times.
And for the bigger project, if we would have to write all the imports, if we would need to create
all our files, if we would need to create all the folders and everything together, you need to understand
that, of course, that would add two or three hours to the project.
And I don't mind adding two or three hours to the project when it comes to functionality, because dad,
of course, is interesting.
But when we talk about boilerplate, I don't really think that you're getting anything out of the fact
that you need to create a file, then you need to create a boilerplate and hopefully you get the idea.
That's why, yes, all the components are already prepared for you as far as the boilerplate and as
far as the import.
So I'll never get back to the content.
I'll just save it.
And then if we take a look at the next folder, we can say that it is going to be a complex.
So, yes, we'll use, of course, the context API.
Now, why this project is going to be interesting because we will use multiple contacts.
So there's going to be one for CA, there's going to be one for filter and there's going to be one for
product and the user.
And you also notice that we'll use use a reduction.
That's why we have special reducers folder.
And in there we have files, we have all the reducers.
And here I right away have all the actions because again, if you take a look at the actions, I did
not really see the point of us typing this together.
So essentially we have the actions and I have the variables that have the string value.
I didn't see any benefit of typing this together with you, since we already know how to create them.
And now back to the context, first of all, why we use use ergaster.
And the story is somewhat simple where when it comes to bigger project, you definitely want to have
the structure.
And previously, before we use reducer, that was a reduction.
Now, with the arrival of user Douceur, it provides that functionality, that structure, because you
need to keep in mind that the bigger your project gets and the more features you're trying to add,
the easier it is to add some kind of box, especially especially if you work as a team.
That's why when it comes to bigger project through enterprise projects, there's always some kind of
structure previously before user register that was a redux.
Now with arrival of user dicer, you can essentially set up everything using the user producer instead.
But I just want to let you know that technically you could have slapped the use state.
So essentially, instead of using user Doozer, you could have set up the state values and you would
be in good shape.
But you need to understand that, of course, eventually, as your project gets bigger, you might run
into some weird bugs because there is no structure.
So even though you might be tempted to think, hey, listen, this user user is way too much work,
you need to understand that it's not because we have a hello world, that it's not like we have just
a simple to do list or whatever.
We have an app where we constantly will be adding more and more features.
So in order to avoid introducing some kind of weird and hard to find bugs, yes, there's going to be
a structure which just means that as we're building the project.
It might get annoying, especially in the beginning, because you might be tempted to think, hey,
listen, I could just add a stat value and I would be in good shape.
Now, if you're familiar with redacts, you know that there's a store and usually there's multiple reducers,
not what user, Dirceu.
It's somewhat of the pain to have that kind of setup.
So instead, we're going to have multiple contacts.
So like I said, we have one for card, one for filter, one for product and one for years.
And also, I wouldn't want to mention that technically we could have set up one global context and then
only one reducer.
Now, what you need to understand, though, is that this global context would be giant because, of
course, we have all this functionality in here and the same would be for reducer.
That's why I split them up, because in my opinion, it is much more easier to navigate around the project
if you have separated the concerns.
Now, if you need to brush up on user user, please do so because of course, I'm assuming that you're
already familiar with, you know, what are the actions, why we're passing in the state and this patch
and all that good stuff.
Then we have the pages.
And essentially these are the same area components.
And of course, the difference is that we will use them as pages in our reactor.
So essentially same components.
We have ones that we're going to use in the pages and then we have the ones that are going to be pages.
And I just split them up in the pages directory.
That's the only thing that I'm doing, because then we have reducers which we already covered.
We have a bit of Yuto functions and I'll talk about them once we get there.
There's really no point of making it more difficult than it should be for now.
Don't worry about them.
And like I said, actions which we're going to use in our use, the reducer, of course, Apgar's.
This is where all our application will meet.
In this case.
We have, of course, the router, we react router and also some components that I would want to display
in every page.
Like I already mentioned, in the US, we have the global styling, but there's going to be specific
styling for the components of that we're going to set up using the excess in jazz style components in
the case.
And then we have indexed jazz.
And in that index, just notice how I'm importing all the contacts.
So I have one for product, one for filter and against card user and also eventually auth provider.
So unlike the previous project where we had one global context and we just wrapped the up.
In this case, you'll see how nasty those particular context, just because we would want to get some
data from one to another one, and when it comes to boilerplate, if you take a look at the any context,
of course, there's going to be the actions that we're going to use.
There's going to be that specific producer that is responsible for filter.
So, for example, filter context is going to filter reducer because, of course, I will use my user,
Dirceu, and then we have some initial site which always is going to be the object.
And then remember the boilerplate, we had some kind of context, whatever is the name.
So whether it's called filter or whatever, then we create that context.
We have the provider that is responsible for wrapping our application and providing this value, which
is just going to be strong at the start.
And then, of course, we use the children since we would want to render whatever is inside of the component
and then we have our hook.
So we have in this case use filter context.
But then you can already guess that for the user, this is going to be use user context and then so
on and so forth.
Hopefully everything is clear.
Hopefully you understand the setup and I guess we'll start by getting to know the styled components.