Some Examples

Code Organization & Project Organization

Have a project structure

• Angular doesn't care how you organize files, but you should.
• Poor file-structure leads to poor code organization.
• Poor code organization leads to spaghetti.

Have a usable project structure

• Project structure should be constantly evaluated.
• Don't start with a grand design. Evolve it.
• Self-documenting project structure is as important as self-documenting code.
• Having a single folder called /scripts, /controllers, or /services will not be suitable as the project grows.
• Examples of Angular Project Organization:
  • Angular Seed
  • Yeoman Angular Generator

Suggested structure from Brian Ford (Angular Team)

                           
root-app-folder
├── index.html
├── scripts
│   ├── controllers
│   │   └── main.js
│   │   └── ...
│   ├── directives
│   │   └── myDirective.js
│   │   └── ...
│   ├── filters
│   │   └── myFilter.js
│   │   └── ...
│   ├── services
│   │   └── myService.js
│   │   └── ...
│   ├── vendor
│   │   ├── angular.js
│   │   ├── angular.min.js
│   │   ├── es5-shim.min.js
│   │   └── json3.min.js
│   └── app.js
├── styles
│   └── ...
└── views
├── main.html
└── ...
                           
                        

Source: http://briantford.com/blog/huuuuuge-angular-apps.html

Be Mindful of file content & Naming

• Each file should contain one Module.
• File names should correspond to the Module they contain.
• Directives namespace should be prefixed to avoid collisions with other libraries like Angular-UI or Angular-Strap.

                        
// snapflow/app/core/controllers/users/UserManageCtrl.js

angular.module('SnapflowApp').controller('UserManageCtrl', function () {
    // ...
});
                        
                        

                        
// snapflow/app/core/directives/pickers/UserPicker.js

angular.module('SnapflowApp').directive('sfUserPicker', function () {
    // ...
});

<div sf-user-picker="params"></div>

                        
                        

Separating Concerns Properly

Following the Zen of Angular

• In initial development and smaller apps, it is easy to get away with writing code in Controllers, but this is a bad practice for larger apps.
• Angular provides Controllers, Services, Filters, and Directives for a reason.
• Our code should be logically divided amongst these.

Some Guidelines

• Handle state logic in Controllers and communicate to Services and Directives
• Handle UI logic in Directives
• Handle business logic in Service/Factories/Providers.

Give code a logic, modular separation of concerns.

                            
angular.module('SnapApp', ['ngResource']);

angular.module('SnapApp').factory('restService', function () {
    // Service Factory for interacting with the REST layer.
});

angular.module('SnapApp').factory('cacheService', function () {
    // Service Factory for interacting with the in-memory cache.
});

github.com/Snapflow/AngularJS-Portland-Meetup-Slideshow


angular.module('SnapApp').factory('appService', function (restService, cacheService) {
    // Service Factory for managing apps and the interacting with the cache.
    var service;
    service = {
        app: {
            get: function (appId, callback) {
                restService.app.get(appId, function (appResponse) {
                    cacheService.app.cacheApp(appResponse, function () {
                        callback(appResponse);
                    });
                });
            },
        }
    }
    return service;
});

angular.module('SnapApp').controller('appController', function ($scope, appService) {
    // Controller for allowing the user to get apps.
    $scope.app = null;
    function getApp(appId, callback) {
        appService.app.get(appId, function (response) {
            $scope.app = response;
        });
    }
    $scope.getApp = getApp;
});
                            
                        

Suggestions for Approach

• You might start with low-level implementations, or high-level implementations (services/factories vs. controllers).
• The most important thing is to constantly evaluate and refactor.

With great $scope, comes great responsibility

Two-way Data-binding is a shiny object

• Template bindings to $scope is one of the best features of Angular, but is often abused.
• The initial tendency is to assign everything to a $scope variable during the initial prototyping of UI.
• When writing larger scale apps, be mindful of bad use of $scope.
• Over-use of $scope can lead to the bad practice of DOM as Database

TDD or die.

Big Web Applications need Testing

• These aren't websites. They approach the complexity of some back-ends.
• Unfortunately, often testing on the front-end is put off until the last minute, when the pain caused by the lack of tests is the most apparent.
• It is very difficult to refactor large code-bases to be testable.
• Within Angular, services are relatively easy to test.

Best Practices

• Get your product team on board with testing.
  • The additional time spent writing tests will pay dividends.
  • A pushed out delivery schedule now is better than a pushed out schedule later.
  • The additional time spent will be less now than later.
• The best approach is to write tests that mimic the acceptance criteria for feature stories, and then write code that pass the tests and full the criteria.