Structure Files for an AngularJS Application
Let's talk about the importance of having a good file structure and how it is is very much like good code in that it is self documenting and friendly to extension. We will introduce the file structure that will serve as the foundation for the rest of the series as we refactor Eggly.
[00:01] 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.
[00:11] 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.
[00:26] I also believe it should promote modular composition, that allows you to extend your file structure indefinitely without interfering with the existing code.
[00:35] 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.
[00:44] 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.
[00:59] 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.
[01:10] 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.
[01:28] 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.
[01:37] 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.
[01:55] We will go over to the "app" directory here, and create a "categories" directory. Within that, we will create a "bookmarks" directory. Now we know that "bookmarks" belongs to "categories." We're also going to create a Javascript and HTML template for each of these features.
[02:21] We're going to create a "categories" Javascript file, and a "categories" template. We're going to do the same for "bookmarks."
[02:36] [silence]
[02:49] 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.
[03:04] 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.
[03:22] 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.
[03:56] [silence]
[03:56] Let's do the same for "edit."
[03:58] [silence]
[04:09] 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.
[04:25] 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.
[04:39] 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.
[04:47] [silence]
[04:47] 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.
[05:22] 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.
[05:50] I'll see you in the next lesson.
Excellent series, many thanks for the excellent work. Just at a level that I could follow. Could you please share how the "resources are pasted into the bottom of the index.HTML file (last few seconds of the video. Steve
Hi, Steve - thanks for the compliment!
If I understand the question correctly, I am just pasting standard script tags pointing to the JavaScript resources that we started to flesh out. I figured pasting them was way more awesome than watching me type them.
Let me know if that answered your question or I totally misunderstood. #highFive
why at https://github.com/eggheadio/egghead-angularjs-eggly-architecture/blob/master/src/app/eggly-app.finish.js you still have $scope.categories = bunch of objects in array? the same for $scope.bookmarks it does not make sense to me because they are in the data folder as json. Please explain.
Hello, Please how are you able to copy all the files into webstorm memory for quick pasting/import in the index.html
@Arnold, unfortunately there was no Webstorm magic here. I just copied the script tags as text and pasted them in the video, simply to cut down the typing time.
I re-watched this video, so this video is talking about making directory structure for large applications that want to share not only feature (or sub-feature) but also micro features (like create / edit).
However the fact that model is not stored in these folders makes me wonder if each folder can be called a feature.
The other thing is that you have to consider, for large applications, there's absolutely a front-end engineering for the look or theme, which is not necessarily the angularJS guy, which is more like front-back guy. In order for this guy to work efficiently, it's better to have a single folder for templates, at least for each feature. Ex.
bookmarks ---- templates ---- scripts ---- styles ---- models
just to reproduce the most of the folders from the root folder, I think this way, you might have a better chance to call it a feature as well as the flexibility to have other expertise on the same project.
I know i might be saying the similar things as my previous post, but after couple of month practice, I realized that a good structure is definitely a good thing to have at the first place, and it also needs some flexibility for other people to contribute.