Abusing $scope inheritance

<div ng-controller="MainController">
  <!-- lots of code -->
  <div ng-controller="ChildController">
    <!-- lots of code -->
    <div ng-controller="GrandchildController">
      <!-- lots of code -->
    </div>
  </div>
</div>

Why this is bad

<div ng-controller="MainController">
  <!-- lots of code -->
  <div ng-controller="ChildController">
    <!-- lots of code -->

    <div ng-if="foo"> <!-- ruh roh! -->

      <div ng-controller="GrandchildController">
        <!-- lots of code -->
      </div>

    </div>
  </div>
</div>

Why this is bad

• Hard to reason about
• Business logic in controller
• How do you grep for this?

What we should have done

• A shared data service
  • Responsible for updating and retrieving data via $http.
  • Controllers call into that service.
• ​Why?
  • More direct and obvious
  • Centralized business logic

Global controller functions

function MyController($scope) {

}

Why this is bad

• Naming collisions
• Can't package controllers into modules
• Encourages GLOF and GLOG
• Not supported by default in 1.3

What we should have done

angular.module("MyControllers")
.controller("MyController", function($scope) {

});

• Why?
  • More modular
  • The global scope is already polluted enough

What we should have really done

No ng-controllers at all

Angular controllers aren't really that modularizable and are dying in Angular 2.0 anyway

http://teropa.info/blog/2014/10/24/how-ive-improved-my-angular-apps-by-banning-ng-controller.html

Scope shadowing

function MyController($scope) {
    $scope.favoriteFood = "stroopwafel";
}

<div ng-controller="MyController">
  <input type="text" ng-model="favoriteFood" />
</div>

Why this is bad

• You will introduce bugs into your app by looking at it.
• Subtle and very hard to find bugs
• No unit test can save you.
• We shed many Angular-shaped tears over this.

Why does this happen?

expect($scope.$parent === $scope.__proto__).toBeTrue();

What we should have done

angular.module("MyControllers")
.controller("MyController", function() {
  this.favoriteFood = "stroopwafel";
  this.someVariable = true;
});

• Why?
  • Eliminates scope shadowing

<div ng-controller="MyController as vm">
  <div ng-if="vm.someVariable">
    <input type="text" ng-model="vm.favoriteFood" />
  </div>
</div>

Alternatively

angular.module("MyControllers")
.controller("MyController", function($scope) {
  $scope.vm = {
    favoriteFood: "stroopwafel",
    someVariable: true
  }
});

<div ng-controller="MyController">
  <div ng-if="vm.someVariable">
    <input type="text" ng-model="vm.favoriteFood" />
  </div>
</div>

Why does this fix it?

<div ng-controller="MyController as vm">
  <div ng-if="vm.someVariable">
    <input type="text" ng-model="vm.favoriteFood" />
  </div>
</div>

In other words:

$scope.$watch for user events

function MyController($scope, $http) {
    $scope.id = 42;
    $http.get("/api/employees/" + $scope.id)
        .success(function(employee) {
            $scope.employee = employee;
        });
    $scope.$watch("employee.title", function(newTitle, oldTitle) {
        if (angular.isDefined(newTitle) && 
               angular.isDefined(oldTitle)) {
            // User changed the title
            $http.put("/api/employees/" + $scope.id, {
                title: newTitle
            });
        } else {
            // Just initial load or first $http.get(). Ignore.
        }
    });
}

Why this is bad

• Difficult to differentiate between user events and programmatic events
  • User click vs. $http response
• Can lead to duplicate PUT requests on page load
  • Very frequent bug for us

What we should have done

• Use ng-change
• Use events
• Flux pattern?

Why?

• One-way data flow is simpler

Rich Hickey on simplicity: https://www.youtube.com/watch?v=rI8tNMsozo0

ng-include

<div ng-controller="MyController">
  <div ng-include="'/partials/bar.html'">
  </div>
</div>

<div>
  {{foo}}
</div>

/partials/bar.html:

• Slow
• Context is hard to determine
• New scope
• Undefined interface for callers

Why it's bad

What we should have done

Element directives

Why?

• Well defined interface
• Easy to grep and reason about
• Components are the future

Passing $scope to a service

function MyController($scope, myService) {
    myService.setFoo($scope);
}

app.service('myService', function() {
    this.setFoo(scope) {
        scope.$watch('thing', function() {
            ...
        });
    }
});

Why it's bad?

• Leaky abstraction
• Your services get view knowledge

What we should have done

• Pass values to services, not $scopes.
• Services can accept callbacks and/or return promises to notify callers of changes.

Home grown build tools

• The "cat" command is not a build system
• GLOF:
    Giant List of Files
• GLOG:
    Giant List of GLOFs
   

Why this is bad

• Easy to break your app through manual dependency management.
• It's difficult to integrate tools like traceur.
• Managing <script> tags manually is painful and error prone.

The ES6 future can be now with the right build tools

What we should have done

   dsmith@laptop:~$ npm install tardis
   dsmith@laptop:~$ tardis travel --year 2015
   dsmith@laptop:~$ npm install webpack
   dsmith@laptop:~$ tardis travel --year 2012

Even then, we'd still have a GLOF.

How to solve this?