Angular Application

Architecture

Otherwise known as "What am I doing?"

Yo

Dave Ackerman, UI Developer at Modus
28 years of Angular experience (rounded down to 1.5)
Follow me! @dmackerman

Agenda

The "problem" with Angular architecture?
Understanding good project structure

Ideal project setup

Build system basics.
The last boilerplate you'll ever need.

So what's the problem?

Angular isn't prescriptive in how we architect our code.
...but engineers like standards.
Angular let's us be flexible in how we
organize code, which can lead to some bad habits.

Let's break bad habits.

This is a structure we see quite often.

 app/
  css/
    app.css
    bootstrap.css
  img/
    pizzas/
      large-pizza.jpg
      small-pizza.jpg
  js/
    app.js
    controllers.js
    directives.js
    filters.js
    services.js
  partials/
    phone-detail.html
    phone-list.html
  index.html
test/
  e2e/
    runner.html
    scenarios.js
  unit/
    controllersSpec.js
    directivesSpec.js
    filtersSpec.js
    servicesSpec.js

Some issues with this:

Quite simply, will not scale. (IE. "there goes your VC funding!)
Unit tests are split across multiple folders.
Functionality is split over multiple folders and files.
Styling not broken down into modular pieces.

Yum.

An alternative

Group files by type of object.

 src/
  app/
    scripts
      controllers
        login-controller.js
        dashboard-controller.js
        delivery-controller.js
      directives
        dropdown-menu.js
        pizza-menu.js
        pizza-picker.js
      filters
        fancy-value.js
      services
        auth-service.js
        data-service.js
    .. app.js

Still not indicating direct relationships between files and functionality.
Could work if you create subfolders. Messy though.

So, let's do it better.

Let's break up functionality by feature!

 src/
  app/
    login/
      _login.scss
      login.js
      login.tpl.html
      login.spec.js
    dashboard/
      _dashboard.scss
      dashboard.js
      dashboard.tpl.html
      dashboard.spec.js
    pizza/
      pizza.js
      pizza.tpl.html
      pizza-detail.tpl.html
      pizza.spec.js
    services/
      data/
        dataService.js
        dataService.spec.js
    app.js
    app.spec.js  <-- unit tests.
  assets/
    fonts/
    images/
  common/
  scss/[less][css]
    main.scss <-- imports out other module level styles and vendor 
  index.html

vendor/ <-- in our .gitignore.

Now we're getting somewhere.

Increased code confidence due to isolated features and tests.
Individual, modular application functionality, organized by feature.
Self contained units including our scripts, styles, templates, and tests.
Test app features as "mini-applications" in isolation.
Easier on-boarding into the codebase.
Spend less time searching for files!

Less Coupling FTW

Cross referencing between features is discouraged.
You'll think twice about creating inter-module dependencies!

Show me!

// app.js
angular.module('pizzaTracker', [
  'pizzaTracker.dashboard', 
  'pizzaTracker.services'
]);

// dashboard.js
angular.module('pizzaTracker.dashboard', [])
.config(function ($stateProvider) {
  $stateProvider.state('/dashboard', {
    templateUrl: 'dashboard/dashboard.html',
    controller: 'DashboardController',
    resolve: {
      activeDeliveries: function ($http) {
        return $http.get('api/news');
      }
    }
  });
})

.controller('DashboardController', function ($scope, activeDeliveries) {
  $scope.deliveries = activeDeliveries;
})

.directive()
.filter()