Note: We have specified an {@link angular.Module AngularJS Module} to load using
`ng-app="phonecatApp"`, where `phonecatApp` is the name of our module. This module will contain
the `PhoneListController`.
## Model and Controller
The data **model** (a simple array of phones in object literal notation) is now instantiated within
the `PhoneListController` **controller**. The **controller** is simply a constructor function that
takes a `$scope` parameter:
**`app/app.js`:** ```js // Define the `phonecatApp` module var phonecatApp = angular.module('phonecatApp', []); // Define the `PhoneListController` controller on the `phonecatApp` module phonecatApp.controller('PhoneListController', function PhoneListController($scope) { $scope.phones = [ { name: 'Nexus S', snippet: 'Fast just got faster with Nexus S.' }, { name: 'Motorola XOOM™ with Wi-Fi', snippet: 'The Next, Next Generation tablet.' }, { name: 'MOTOROLA XOOM™', snippet: 'The Next, Next Generation tablet.' } ]; }); ``` Here we declared a controller called `PhoneListController` and registered it in an AngularJS module, `phonecatApp`. Notice that our `ngApp` directive (on the `` tag) now specifies the `phonecatApp` module name as the module to load when bootstrapping the application. Although the controller is not yet doing very much, it plays a crucial role. By providing context for our data model, the controller allows us to establish data-binding between the model and the view. We connected the dots between the presentation, data, and logic components as follows: * The {@link ngController ngController} directive, located on the `` tag, references the name of our controller, `PhoneListController` (located in the JavaScript file `app.js`). * The `PhoneListController` controller attaches the phone data to the `$scope` that was injected into our controller function. This _scope_ is a prototypal descendant of the _root scope_ that was created when the application was defined. This controller scope is available to all bindings located within the `` tag. ### Scope The concept of a scope in AngularJS is crucial. A scope can be seen as the glue which allows the template, model, and controller to work together. AngularJS uses scopes, along with the information contained in the template, data model, and controller, to keep models and views separate, but in sync. Any changes made to the model are reflected in the view; any changes that occur in the view are reflected in the model. To learn more about AngularJS scopes, see the {@link ng.$rootScope.Scope AngularJS scope documentation}.
AngularJS scopes prototypically inherit from their parent scope, all the way up to the *root scope* of the application. As a result, assigning values directly on the scope makes it easy to share data across different parts of the page and create interactive applications. While this approach works for prototypes and smaller applications, it quickly leads to tight coupling and difficulty to reason about changes in our data model.
In the next step, we will learn how to better organize our code, by "packaging" related pieces of application and presentation logic into isolated, reusable entities, called components.
**`app/app.spec.js`:** ```js describe('PhoneListController', function() { beforeEach(module('phonecatApp')); it('should create a `phones` model with 3 phones', inject(function($controller) { var scope = {}; var ctrl = $controller('PhoneListController', {$scope: scope}); expect(scope.phones.length).toBe(3); })); }); ``` * Before each test we tell AngularJS to load the `phonecatApp` module. * We ask AngularJS to `inject` the `$controller` service into our test function. * We use `$controller` to create an instance of the `PhoneListController`. * With this instance, we verify that the phones array property on the scope contains three records.
**A note on file naming:**
As already mentioned in the [introduction](tutorial/#running-unit-tests), the unit test files (specs) are kept side-by-side with the application code. We name our specs after the file containing the code to be tested plus a specific suffix to distinguish them from files containing application code. Note that test files are still plain JavaScript files, so they have a `.js` file extension.
In this tutorial, we are using the `.spec` suffix. So the test file corresponding to `something.js` would be called `something.spec.js`. (Another common convention is to use a `_spec` or `_test` suffix.)
...
browsers: ['Chrome'],
...
* You should see the following or similar output in the terminal:
INFO [karma]: Karma server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome
INFO [Chrome 49.0]: Connected on socket ... with id ...
Chrome 49.0: Executed 1 of 1 SUCCESS (0.05 secs / 0.04 secs)
Yay! The test passed! Or not...
* To rerun the tests, just change any of the source or test `.js` files. Karma will notice the change
and will rerun the tests for you. Now isn't that sweet?
Make sure you don't minimize the browser that Karma opened. On some OS, memory assigned to a
minimized browser is limited, which results in your karma tests running extremely slow.
## Experiments
* Add another binding to `index.html`. For example:
```html
Total number of phones: {{phones.length}}
``` * Create a new model property in the controller and bind to it from the template. For example: ```js $scope.name = 'world'; ``` Then add a new binding to `index.html`: ```htmlHello, {{name}}!
``` Refresh your browser and verify that it says 'Hello, world!'. * Update the unit test for the controller in `app/app.spec.js` to reflect the previous change. For example by adding: ```js expect(scope.name).toBe('world'); ``` * Create a repeater in `index.html` that constructs a simple table: ```html| Row number |
|---|
| {{i}} |
| Row number |
|---|
| {{i+1}} |