this is what angular feels like, a bit

In the last two weeks of my Code Fellows Ruby on Rails bootcamp, we’re focusing on JavaScript, JQuery, and all their friends. This week we kick off with Angular. Angular is a JavaScript tool created by Google for fast, responsive websites. I completed the (free) Code School course “Shaping Up With Angular” and I’m about to embark on a quest to connect it to a persistent database. In my case it will be a Ruby on Rails app.

But first, let’s talk Angular!

MODULE

When you create a JavaScript file to hold some Angular, you initialize it like so:

var app = angular.module('gemStore', ['store-products']);

if you’re not well-versed in JavaScript, this is essentially saying: Declare a variable “app” and set it equal to an Angular module named “gemStore” that depends on another module named “store-products.” Once you’ve declared at least one module, you can get going filling it up with useful stuff like…

CONTROLLERS & DIRECTIVES

Controllers work similar to how they work in Rails. You can set up and assign a controller to a specific part of your webpage, and it can render and manipulate data in a variety of ways. In the tutorial, we set up controllers to manage information about the gems, the product tabs, product reviews, etc. If your code is getting repetitive and/or you want to isolate specific chunks of the page, you can create directives instead that will load a separate html page using naming-conventions (much like how Rails renders partials). Depending on what you’re trying to do, you may be able to include controller functions in a new directive and eliminate the need for a separate controller altogether. Neat!

SCOPE

Angular controllers are called on specific DOM elements , and operate within the scope of that element only. So for example, here’s some pseudocode:

<section id=gems ng-controller="gemController">
  <unordered list of gems>
    <gem 1>
    <gem 2>
    <gem 3>
  <end of list>
<end of section>

Outside this lovely, contained section, if you want information about gems you are entirely out of luck. Note how any of the list objects know about gems (and any child elements we might create under them, if we so choose)–basically anything that’s in the gem section family.

But not outside that family. They know about other stuff, maybe. Like maybe they know about…

DATA BINDING

If you’ve ever typed on a website and had text show up magically elsewhere, tracking as you type, that’s a two-way data-binding and Angular is a pro at it. Here, why don’t you go make some boxes to see how it works? Hmmmm… boxes. That’s not very try angular. Get it, triangular? I feel like this demo could be improved… perhaps a project for a rainy day…

DEPENDENCY INJECTION

Wow, that one sounds pretty grim, right? Coffee is my dependency injection these days. But we already saw this above — you remember in that top example how my app.js had an array of one element — it looked like this:

angular.module('gemStore', ['store-products']);

The app can’t run without the file where I’ve created a module named ‘store-products’, so injecting the dependency here tells my app where to look to import that info. Once it knows how to read ‘store-products’, it inherits any and all controllers and directives in that dependency JavaScript file, and the app can load as usual. Quickly, we hope!

Ok, off I go to attach this gemstore to a database… wish me luck and above-average retention as we dive into the last week of instruction (#justkeepswimming).