Angular modules
building your module dependency tree
Me
Will Hoag
Animator / Engineer
Contact:
will@flipbox.io
Links:
Modularity
by
building a large app out of a bunch of small apps
The module dependency Tree
organizing the apps by feature and declaring dependancies between them
File Structure might look like:
(Module Declaration Files)
- app/
- modules/ (scripts)
- app.coffee
- feature1/
-
feature1.coffee
- services/...
- directives/...
- view1/
- view2.coffee
- directives/...
- controllers/...
APP MODULE
just need to list your views as your dependancies
angular.module('myApp', [
myApp.profile_view1,
myApp.account_view2
])
VIEW MODULE
list all dependancies for the specific view / state
angular.module('myApp.profile_view1, [
'ui.router',
'myApp.user'
'myApp.profile'
])
feature modules
then setup your feature modules
angular.module('myApp.user, [myApp.userApi])
angular.module('myApp.profile, [myApp.profileApi])
MODULE declaration files
A good place to handle things like module specific:
routes/states on view modules
angular.module('myApp.account_view', ['ui.router'])
.config ($stateProvider) ->
$stateProvider.state 'account',
url: '/:userid'
templateUrl: 'modules/account_view/templates/..._view.tpl.html'
controller: 'AccountViewCtrl'
angular.module('myApp.profile_view', ['ui.router'])
.config ($stateProvider) ->
$stateProvider.state 'profile',
url: '/:userid'
templateUrl: 'modules/profile_view/templates/..._view.tpl.html'
controller: 'ProfileViewCtrl'
service modules
Configure Interceptors
angular.module('myApp.api', ['myApp.config', 'ngCookies'])
.config ($httpProvider) ->
$httpProvider.interceptors.push ['apiInterceptor', (apiInterceptor) ->
return apiInterceptor
]
React to Events
angular.module('myApp.user', [])
.run ($rootScope, user) ->
$rootScope.$on "appName.api.unauthorized", ->
user.logout()
Notes on name.spacing.modules
Best practice is to use dot notation to specify relationships.
(not dependancies)
"myApp.view"
"myApp.featureA"
"myApp.featureA.utility "
BENEFITS
-
decoupling
-
code-reuse
-
less to load for your tests
-
structural clarity
-
functional grouping
Decoupling
-
Separating code into modules encourages separation of logic
code reuse
-
any module without dependancies can be moved to another application easily because all of the functionality is grouped into a single folder
- otherwise dependancies are easy to spot and carry over as well
less to load for your tests
-
load only what you need in tests
-
instead of loading your entire application for every unit test, now you only have to load the specific module
- and with the less code, there will be less to mocking to do
Structural CLARITY
- easy to see what your module depends on and what it affects
- this is good for yourself 6+ months down the road and anyone new to your codebase
Functional grouping
- handling routes, config, and run stages for each module is a nice way to group functionality that relate to each other
Links
13 Steps to AngularJS Modularization
Scalable code organization in AngularJS
Good seed example
NG-BOILERPLATE
Thanks!
slides can be found here: