All right.
So we got redux working, nicely with our app.
We've just learned an awesome library.
I hope, everybody is feeling good. Now,
I do want to add a few things.
Obviously, this is a simple example. But the fundamentals are there. Using these principles, you can
go off and build, larger and larger applications.
But as I've been writing this, you may have noticed a few things.
One,
well, let's look over here at our folder structure. We can imagine as our app grows that is going to get
bigger and bigger and bigger.
And this is actually something I'm going to demonstrate to you later on in the course, when we work on the
smart brain app. Where we start loading our app js, with a ton of functions.
And we're not using redux for it.
So this file gets longer and longer with new methods and new methods and new methods.
Now, having one container component, that is having one connected component. A component that knows that
the redux store exists and listens to props and dispatch actions from it.
Well, having just one is not really realistic.
Most likely you're going to have multiple containers. But because of the way redux works, that's fairly
easy to do.
We can just use connect and pick and choose which components, we want to connect to the redux store.
And if we want, two containers to speak to each other,
well, very simple, we just connect them.
And because the store is up above everything else, we're able to get that state information.
So it makes communication very very easy.
So we obviously want to have containers like this. And simple presentational components that are just
pure functions, that just receive props and render.
However, as we grow more and more components, and more and more containers, it starts to make sense to
not have just one 'constants' file, one 'actions' file and one 'reducers' file.
You can imagine these getting bigger and bigger and bigger. And you'll see projects that have a 'actions'
folder, a 'constants' folder and a 'reducers' folder.
But I personally like the component way of doing things.
That is, group everything according to the component.
For example, create an app dot js or let's say, there's a smart search field component.
We're going to create a folder, called 'search field' and that 'search field' folder is going to have all
the DOM presentational components, that it needs.
It's going to have all the 'actions' that it needs in action dot
js. It's going to have all the 'reducer' that it needs.
And it's also going to have all the constant that
it needs. So each folder is going to represents a component, a chunk of our website and it's all coupled together
in one little folder.
So, if we ever want to share code, it's going to be fairly easy to do.
It's also really nice to think about it that way. Instead of having these massive general folder names.
And that's what you'll see with most big projects.
This idea of components, that have their own folders, these containers that again have their own folders,
as well as reducers and actions.
And this way you can read through the folder structure and decide where you want to go to fix a bug
or create a new feature.
You also want to avoid repeating code as much.
For example, in most applications, we're going to have a lot of fetch call.
So wouldn't it be great, if we had an API folder here, that does the fetch call, maybe we'll call it API,
'get API' and all we need to do is pass a function, and that function is going to pass that url into
the fetch function and it's also going to do this
json for us. So its just going to return the data.
So we keep repe.., so we stop repeating all this fetch dot then dot then dot catch. So, thinking in terms of
organizing your folders, to something that makes sense, something that can scale.
And, if somebody comes on to the project, it makes it easy for them to follow and read, is a good way of
doing things.
All right, that's enough for now.
I'll see you in the next video.
Bye-bye