Hello, this is Lukas Ruebbelke. In this lesson we're going to address one of the most fundamental principles of good architecture, and that is the file structure.
The goal of a sound file structure is the same as the code that lives within it. A file structure should be self-documented, to indicate intent. It should also lend itself to efficiency, and ability to locate resources quickly.
I also believe it should promote modular composition, that allows you to extend your file structure indefinitely without interfering with the existing code.
This can be more art than science, and so I'm going to present one way to do it that has worked well for some very large Angular projects.
I'm not going to get religious about details that hang in the balance of opinion. I would urge you, though, to favor consistency above all else, regardless of the specific details that you choose to implement.
Normally a file structure would grow organically, but we have a unique opportunity to see a file structure come together all at once, because we are re-factoring an existing project.
With that said, we want to organize our code by features, and not by type. For instance, we're not going to put all of our controllers into a single folder, our services into another folder, our directives into another folder, etcetera. This makes it very hard to pick up a single feature and move it somewhere else.
It also makes testing a single feature isolation really difficult, because you have to reach into quite a few places to get the dependencies that you need.
To illustrate this in action, we know that eggly has two main features, "categories" and "bookmarks." We know that "bookmarks" actually belongs to "categories," so let's create a file structure that indicates this relationship.
By grouping these files together, it makes it really easy to locate a single piece of functionality, and navigation is kept to a minimum. When we get to the testing series of eggly, this is also where the specs would live.
We also have two unique states within "bookmarks" that we have defined as well. These are creating a bookmark, and editing a bookmark. Let's create the file structure within "bookmarks" to illustrate this relationship.
We're going to create a "create" directory, and we're also going to create an "edit" directory. Within these directories, we're able to encapsulate creating- or editing-specific code and templates.
Let's do the same for "edit."
Now you can look at these file names, and you know exactly what they do, but also the directories that they live in. It's very easy to ascertain the intent of what they do, and the relationship that they have with the rest of the project.
One more thing that I want to address in this video, that comes up when talking about files, is where do you put something that needs to be shared across features? The answer is that common features should go in a common directory.
This is where I create most of my models, such as the "bookmarks" and "categories" model, so let's build out that structure real quick.
Within the app directory, so essentially on the same hierarchical level as "categories," we are going to create a "common" directory. Within there we're going to create a "models" directory. We will create a "bookmarks" model, and a "categories" model.
Now that these files and folders have been created, we just need to include the resources into our main HTML file. We'll jump down here to the bottom, paste these in. This sets us up perfectly for our next lesson, where I will show you how to use sub-modules to organize the code that will actually live within these files.
I'll see you in the next lesson.