This lesson is for PRO members.

Unlock this lesson NOW!
Already subscribed? sign in

AngularJS Architecture: File Structure

5:51 Angular 1.x lesson by

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.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

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.

Avatar
Fang

I really appreciate that you spent time in discussing file structure. From the past experience, just by looking at it, it might tell you if a project is going to fail or not.

In your video, you mentioned that you favor organizing by features and not by type. This is very true. You treat each angularJS module as a feature, and inside it you continue use submodule approach. However it's still a mixed model, ex. asset and data folder as well as your common/models folder. It's not 100% by-feature structure.

While this approach may be very effective for very large application which can have submodule inside module. But a typical application might be better in the following way.

First use module to organize functionalities. And we have a folder for all modules (there'll be dependency, but we won't track them by embedding one inside another one).

Inside each module, we'll organize by type, ex. template, script, data, model etc.

This two layer of file structure, by feature first and then by type serves me well for medium size application. For small application, i just organize by type or not organize at all.

This approach also scales well, because it's essentially flat except it's grouped by feature (which is a tag to the type folder inside).

In reply to egghead.io
Avatar
Joel

You make great points Feng. For even smaller applications, we might not need folders at all! ;)

I love this explanation.

In reply to Fang
Avatar
Fang

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.

Avatar
Steve

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

Avatar
Lukas

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

In reply to Steve
Avatar
Victor Alfonso Hazbun Anuff

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.

Avatar
Arnold

Hello, Please how are you able to copy all the files into webstorm memory for quick pasting/import in the index.html

Avatar
Lukas

@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.

In reply to Arnold

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.

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.

We're going to create a "categories" Javascript file, and a "categories" template. We're going to do the same for "bookmarks."

[silence]

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.

[silence]

Let's do the same for "edit."

[silence]

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.

[silence]

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.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?