Organize Code with Sub-Modules into an AngularJS Application
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.
[00:01] 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.
[00:11] 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.
[00:27] 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.
[00:38] Let's start with the models first, since they are common and we will need them as we get into specific features.
[00:47] 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."
[01:13] 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.
[01:35] 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.
[02:10] 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.
[02:28] 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.
[03:01] We also need to expose the "edit" and "create" sub-module, so we will go here and just type these in.
[03:17] 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.
[03:45] 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.
[04:03] 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.
I suppose this is fairly arbitrary, but might you call the
eggly.models.bookmarksmodule,eggly.models.categories.bookmarksfollowing the hierarchy of the app? Is there a particular reason why you didn't do this?