Beyond
`ng-hello-world`

Building Real World
Web Apps with AngularJS

by Rob Friesel

What are we talking about?

open source
from Google
for building complex web apps

...a toolset for building the framework most suited to your application development.

What are we not talking about?

"the basics"
comprehensive feature coverage
side-by-side comparisons
pros/cons of single-page apps

AngularJS

a lightning tour

MVW¹!

1: "M-V-Whatever"

Customary Features!

declarative data-binding
client-side controllers
separation of concerns

Opinionated in the Middle

* some explanation is in order * UN-opinionated about models ("mostly") * c/w Backbone, Ember * UN-opinionated about views ("mostly") * we've heard this before * (Murphey, 2012; re: Backbone) * similar critique as hers? * and/but (TO TOTALLY UNDERMINE MYSELF HERE...) plenty of "magic" in the views by way of directives * "So why _opinionated in the middle_ ?" * RE: opinions about how to separate code * RE: opinions about how to re-use code * RE: opinions about how to fit things together * examples: * controllers call services directly * directives get their own scope whenever possible * (_WHAT ELSE?_) * "Does this all seem like common sense?"

a trivial example

The Angular Way

"lethally allergic to global state"

"Hands off the DOM."

"extend HTML vocabulary"

The Mechanics

Controllers & $scope
Services
Filters
Directives

controllers & `$scope`

* "familiar with controllers" * from other MVCs... * arguably more of a "ViewModel" * c/w Knockout.js * main function of controller: * set up execution context for your views * that's `$scope` * putting your data onto `$scope` * putting your methods etc. onto `$scope` * example: * `ng-hide="{{ thing == true }}"` * and/but have that more than once and consider * `ng-hide="hasThing()"` * yes: you can have more than 1 per "page" * and you _should_ b/c each controller should really just be responsible for _one thing_ * `$scope` inheritance * as prototypal... * controllers w/in controllers... * directives w/in controllers * `$scope.thing` ... `thing` may _actually_ be from `$scope.$parent` * see also: `$rootScope`

example controller


angular.module('books').controller('BookListController', [
  // set up dependency injection:
  '$scope', '$window',
  // controller (DI through function arguments)
  function($scope, $window) {
    $scope.books = $window.BOOKS;

    $scope.getStarClass = function(rating, compare) {
      return 'glyphicon glyphicon-star' +
        ((rating > compare) ? '' : '-empty');
    };

    // and so on
  }
]);

...and hook it up


<!DOCTYPE html>
<html lang="en" ng-app="books">

  <body>
    <div ng-controller="BookListController">
      <table>
        <tr ng-repeat="book in books">
          <td>{{book.title}}</td>
          <td>{{book.author}}</td>
          <td>{{book.rating}}</td>
        </tr>
      </table>
    </div>
  </body>

</html>

roughly illustrated

Services

* anything you want to share b/w controllers * you're not setting up inheritance chains b/w controllers * share code through DI * side note: the "DI" bit bothers me - you're just passing references to the service singletons into your controllers as function args * _anyway_ - "inject" as args into contructor functions for controllers, directives, other services * side note: the DI winds up feeling a bit like "ceremony" * THINK FUNCTIONALLY HERE * w/ services you don't want side effects * (just arguments and return values) * (side note: Angular is designed to not have side effects - remember: "lethally allergic to global state")

example service


angular.module('books').factory('goodreadsService', ['$http',
  function($http) {
    function getShelf(userId, shelf) {
      return $http.get(GOODREADS_HOST + REVIEWS_LIST, {
        params: {
          v: 2, key: API_KEY,
          id: userId, shelf: shelf
        }
      });
    }

    return {
      getShelf: getShelf
    };
  }
]);

Filters

example filter


angular.module('books').filter('dropSubTitle', [
  function() {
    return function(input, token) {
      return input.split(token || ':')[0];
    };
  }
]);

...and using it


<ul>
  <li ng-repeat="book in books">
    <em ng-bind="book.title | dropSubTitle:'-'"></em> by
    <span ng-bind="book.author"></span>
  </li>
</ul>

Directives

example directive


angular.module('books').directive('grRating', [
  function() {
    return {
      replace: true,
      restrict: 'AC',
      templateUrl: '/ng-templates/gr-rating',
      scope: { rating: '=' },
      link: function(scope, element, attrs) {
        scope.getStarCss = function(compare) {
          return 'glyphicon-star' +
            ((scope.rating > compare) ? '' : '-empty';
        };
      }
    };
  }
]);

/ng-templates/gr-rating


<div>
  <span class="glyphicon" ng-class="getStarCss(0)"></span>
  <span class="glyphicon" ng-class="getStarCss(1)"></span>
  <span class="glyphicon" ng-class="getStarCss(2)"></span>
  <span class="glyphicon" ng-class="getStarCss(3)"></span>
  <span class="glyphicon" ng-class="getStarCss(4)"></span>
</div>

using that directive


<div ng-controller="BookListController">
  <ul>
    <li ng-repeat="book in books">

      <!-- and our directive: -->
      <span gr-rating data-rating="book.rating"></span>

    </li>
  </ul>
</div>

...and much more!

core APIs
jqLite
routes
$apply, $digest, and $watch...
testing

* plenty I'm not covering here * core APIs * called "global APIs" in the docs * but hey... "global" is a dirty word * the point: some utils to help keep other libraries out * not _to_ keep them out but: why bring in all of jQuery if all you need are some simple selectors? * which leads us to... * jqLite (explain!) * routes (for making sane and sensible and shareable URLs for client-side state...) * `$apply`, `$digest`, + `$watch` * noted: some of the "magic" around `$scope` objects * the digests are on short but regular intervals * ...to try to prevent ng from performing poorly * "don't watch yourself to death" * some added security there - i.e., throw errors if items in the apply/digest loop start setting each other recursively and dangerously * testing (testable out of the box!)

Tripoli

a case study

real quick:

What is Tripoli?

...leveraging ZooKeeper, we at Dealer.com have built a centralized, remote configuration service that provides consistent, flexible and accountable configurations to applications in our enterprise.

Tripoli is the front-end for that

Let's have a quick look...

Why Angular?

Separation of Concerns

Idiomatic

Velocity

Modules

Great Developer Community

...and getting better all the time

"It's just JavaScript!"

Testable

Difficulties, Hitches, Pitfalls, Problems, and Other Realities

Documentation

Not Actually That Great

Examples

Not Always the Safest

Bad Example


// taken right from the AngularJS home page...
function TodoCtrl($scope) {
  $scope.todos = [ /*todos...*/ ];
  // etc.
}

"Where do I begin?"

* tutorial is OK and/but... * difficult to know where to start with some of ng's concepts/features * given that the examples appear to lead you ever so slightly astray, there is an argument to make there that the credibility is a bit hurt * BACK UP : most things you _can_ just pick up and start using * BUT again ng is more of a fwk than a lib * and as such: you're using it to "build apps" * you _can_ just sprinkle a little bit in to your existing apps * but I'm not sure that that's where you'll get the most value (i.e., best results from going all in?) * in other words: although you _can_ try to just sprinkle it in a little bit at a time to experiment with it, you're likely to get better results if you do some up-front research and design...

Whither Animation?

* all that "hands off the DOM" business... * great for decoupling, great for arch. * and/but: "You're a UI developer and you care about that fit-and-finish that goes in to the end result..." * animations are not always gratuitous * they're part of "surprise and delight" * they're part of your brand * and they can serve a _function_ in your UI as well * (but you already know this...) * ng can make this... difficult sometimes * through 1.0.8 there is nothing build-in * and the 1.1.x stuff is unstable * and I can't say I've figured out the 1.2.0 animation support yet * (and/but: links!) * you can get down into the directives to do some of this * recall: directive are where it's "safe" to do DOM manipulation * and/but : pros and cons here * restricting DOM manipulation to directives makes a lot of sense * but sometimes it also feels like overkill?

`$apply` and the `$digest`

"slippery scope"

* ng does a lot of work "for you" w/r/t/ tracking values that are attached to `$scope` * (that's the `$digest`) * and/but it isn't always clear how or why or when you can update items directly and have it "just work" and when you need to hit it `$apply` * the rule of thumb from the docs: use `$apply` whenever "non-ng" code is updating values in ng scopes * which seems like a simple enough rule except... * ...when you _do_ update w/o `$apply` and think that you _should have_ but then it just works anyway; vs. * ...when you update a value fr/ w/in ng but it doesn't (appear) to update the way it "should" * CAN BE CONFUSING * also: be doubly careful w/ the latter case: it's almost too easy to think "oh I just need to wrap that in an `$apply`" and then you get that error about already being in a `$digest` cycle etc.

Temptation to Fight the Framework

* the temptation is strong * b/c ng is probably quite unlike any front-end fwk you've dealt with before * anecdote: events * I wanted to use events in a certain way... * ...b/c that's how I've done it in other fwks (e.g., ExtJS) * ...but Stack Overflow thread leads us to a classic case of "you're doing it wrong" * observation: temptation to use `$scope` as model * controversy: the `ng-` attrs... * they _feel_ dirty * b/c we've spent the last couple years arguing about `onclick` + the like * "decouple your HTML and JS!" * will feel like _that_ * see also: that HN thread from 6 months ago... * ANYWAY: don't think of it as tightly coupling your DOM to your JS; think of it as turning your HTML into a potent DSL for your app * (starting to sound like a selling point, eh?)

Putting It All Together

Be Conservative with Controllers

Be Liberal with Directives

Organize Your Code Early

Example Angular File Organization


web-app/
  js/
    ng-app-base.js
    controllers/
      ExampleController.js
    directives/
      ngxDirective.js
    filters/
      filterName.js
    services/
      exampleService.js
    lib/
templates/
  _ngxDirective

* variation on Angular Seed * "...but better!" * `ng-app-base.js` (or eq.) is where your modules are declared, where you do global config, etc. * separate directory for each type * each type gets its own file * (you're concat'ing and min'ing anyway, right?) * each file should match what is inside * makes everything easy to find * templates: each partial name should match the directive that it corresponds with * (we use Grails so ours went into...) * side note: directive namespace! decide on one early * use a good (short!) one for your app-specific stuff * and if you can't decide on one... use `ngx-` * for "ng-extended"