Over a million developers have joined DZone.

Some opinions on developing with AngularJS

DZone 's Guide to

Some opinions on developing with AngularJS

· Web Dev Zone ·
Free Resource

I gave a short internal talk today at ThoughtWorks about my experiences working with AngularJS. Peppered in this discussion were several of my opinions on what practices/libraries I’d consider using while working on an AngularJS app.

I’ve listed them down here, in no particular order. They are succinct; I may expand on them with code examples. The [R] prefix before a point indicates a recommendation.

  • MVC
    • Model
      • Plain Javascript objects
      • Because of this, AngularJS has to do dirty checking n times until a model “stabilises”, just in case listeners modify the model.
    • View
      • Angular’s own templating engine / {{Angular expressions}} are shorthand for watch expressions. Explicit $watch expressions may be provided for a more complex listener.
      • Can include partial views.
      • [R] Recommend breakup of complex views into multiple partials, each with its own controller.
      • Directives are like custom HTML tags which can render custom content. *[R] Use them sparingly, too many properties on them implies you should break it up into multiple directives, or any other refactoring you’d normally do to break up big classes.
    • Controller
      • Controllers have their own scopes/namespace. Scope objects are available through the $scope variable. Scope variables are implicitly available to the view.
      • Controllers are wired through routes.
      • Scopes can be nested. Nested controllers correspond to nested scopes. If a scope variable is not defined, it will be searched for in all of its ancestor, till $rootScope is reached.
      • [R] Communicating between controllers/scopes: use shared services, or use broadcast/emit events. Controllers can listen “on” events.
  • Modules
    • One-to-one correspondence with an app.
    • is a shortcut to bootstrapping modules.
    • Configuration involves:
      • Setting up services
      • Setting up routes
  • Services
    • Objects/functions/anything that needs to be a “global” dependency, used by controllers
    • Lazy loaded
    • Suitable for server API endpoints
    • [R] Good abstraction layer option for bare $http
    • [R] Recommended way to share data between controllers, but don’t forget broadcast/emit events may be more appropriate in many cases.
    • [R] Recommend services are objects with a get() method, let them return promises.
  • Dependency Injection

    • Service Locator-ish, tag-based, using annotateFn(), which extracts dependency names from argument lists.
    • [R] Use these only for services, endpoints, and sharing “global” data, because they aren’t necessarily portable.
    • [R] Use RequireJS for domain logic objects, utility-type libraries. Not using RequireJS requires either a ton of script src tags or a lot of code in a single class.
  • Promises

    • [R] Use them for services.
    • [R] Use them as wrappers for long running promises, to show loading screens.
    • [R] Can even wrap events as promises, if promise is not directly available.
    • Angular has a service called $q, which provides facilities similar to Q standalone, Angular templating engine recognises it (promises can be angular expressions). But $q is a subset of Q. Up to you to decide which would be a better fit.
  • RequireJS

    • [R] No need to use it at the top to bootstrap Angular, if you encounter any critics.
    • [R] Use it for all dependencies below the controller level, as you see fit.
    • What happens when you don’t break up scripts?
  • Testing

    • We used Mocha. Angular docs talk of using Jasmine. Recommendations are:
      • Use chai and chai-as-promised.
      • Use mocha and mocha-as-promised.
    • [R] Last declaration wins. That’s how you mock out dependencies.
    • E2E tests let you assert directly on document elements, Angular uses a subset of jQuery.

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}