Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Some opinions on developing with AngularJS

DZone's Guide to

Some opinions on developing with AngularJS

· Web Dev Zone ·
Free Resource

Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.

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.

Monitor application stability with Bugsnag to decide if your engineering team should be building new features on your roadmap or fixing bugs to stabilize your application.Try it free.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}