Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Organize Code with Sub-Modules into an AngularJS Application

    Lukas RuebbelkeLukas Ruebbelke

    Let's look at sub-modules as a mechanism for organizing our code into logical containers that we can then compose into our main application. Leveraging sub-modules is a powerful way to add in new functionality and features into an application while minimizing the impact that it has on the existing code base.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson




    Hello. Welcome back. This is Lucas Ruebbelke, and in this lesson I am going to show you how to organize your code into logical containers using sub-modules.

    Modules in AngularJS are just that, containers. They allow you to separate your code by features and then when you need to access that functionality in other parts of your application, you just need to inject that module as a dependency.

    We already have a hint of the sub-modules that will exist because our file structure has done a really good job of defining the relationships that exist within the eggly application.

    Let's start with the models first, since they are common and we will need them as we get into specific features.

    Jumping into the "bookmarks-model" file, we are going to call this sub-module "eggly.models.bookmarks." Then in the "categories-model," we are going to call this "eggly.models.categories."

    From here, let's go into the "categories" and we will create a "categories" module. In the "bookmarks," we will create a "categories.bookmarks" module.

    Let us do the same for edit and create. We will call this...again, just being self-documenting, so somebody looks at the sub-module, they know by the name of it exactly what it does.

    We've actually defined all of the modules for the application, but we have not actually connected any of them yet. The "categories" module will obviously need to communicate with the "categories-model" sub-module, so let's inject that now.

    If we go here to the second parameter, we will just inject this here. We simply need to put the string of the name that we called that sub-module. Then let's go to the bookmarks, and the "bookmarks" sub-module actually needs the "categories" and the "bookmarks" model.

    We also need to expose the "edit" and "create" sub-module, so we will go here and just type these in.

    Now we go into our main application and we just need to inject the "categories" sub-module and the "categories.bookmarks" sub-module. When you include a sub-module into a another sub-module, and then that sub-module into the main module, it's a transitive relationship.

    Because we included the "edit" and "create" sub-modules into "bookmarks," it's now available to the main eggly application. It's, again, almost like a file structure but with containers, aka sub-modules.

    Now we have a self-documenting file structure and we've established the programmatic relationships via sub-modules. Things are going to get really interesting as we learn how to navigate between these entities and their states in the next lesson, where I will introduce UI router and state machines. See you in the next lesson.