← Blog Home

AngularJS Best Practices: I’ve Been Doing It Wrong! Part 3 of 3

9 Replies.

AngularJS-large

Three sanity-preserving ideas that will make me and you 10x more productive with real-world AngularJS applications

This is the last in a three-part series on practical large-scale development with AngularJS. The TL;DR version is at the end of the article. If you have not read the first two parts (part 1, part 2), you might want to start with them. They lay out the foundation for the structure of a large-scale AngularJS project, and automatic testing with AngularJS and ng-boilerplate project template. In this part, I’ll list the common pitfalls to be avoided, best practices to be followed, and specific areas that need our attention as we transition from years of jQuery development into our first well-designed and well-tested large-scale Angular projects.

Quit jQuery for a While

Forget jQuery

To teach your brain the habits of an AngularJS superhero, you need to free your mind from the reflexes ingrained in you after years of jQuery practice.

I’ve highlighted some parts of Angular that may be unexpected to a jQuery-trained brain in an earlier post, AngularJS for jQuery Developers. The best way to get free from jQuery reflexes in Angular projects is to avoid using jQuery completely, at least until you master the new way.

In jQuery, DOM is the center of developer’s attention. You start with designing the web page, you manipulate DOM with jQuery, you even store the state associated with DOM in DOM. So in jQuery world, DOM is both your model and view. This becomes unnecessary when you have two-way data binding and a magical way to create new tags and attributes with AngularJS directives. With AngularJS, you are a wizard who can augment HTML, the very language of  the web.

So, don’t start your app development with DOM or visual design. Instead, begin with application architecture. After you’ve decided what is it that your app does, and what data structures you’ll need for this, what logical parts will become controllers, you can design the views based on that.

Scopes are Important

Scopes are the meat-and-potatoes of AngularJS, so it’s a good idea to become really comfortable with them – know when scopes are created and destroyed, how inheritance and data exchange works between them, and how re-evaluation process works. There’s an excellent article on scopes at “The Nitty Gritty“, go read it please. Here’s a brief summary of scope-related advice from the article:

  • Do not use [expensive] functions in expressions (in templates) – they are re-evaluated often
  • Use $scope.$apply() when applying external data changes (e.g. callback from outside AngularJS)
  • Never store references to DOM elements in the scope
  • Do not access the DOM outside of a directive
  • Be aware of the parent-child relationships between scopes and their data.

Equivalents of Familiar Functions

Replace window.setTimeout with $timeout, $.ajax with $http (or better yet, use resources and models), and get familiar with $q promises. All these things play nicely with Angular evaluation loop, and you do not have to worry about calling $digest or $apply manually.

Check out the global APIs in Angular documentation – it has a rich set of utility functions that you need on a daily basis. Here are a few:

Companion Libraries

While I was writing this triad of articles, Josh David Miller has released version 0.2 of his awesome boilerplate. (I am not affiliated with it in any way, I just think it’s a collection of really good ideas, all in one place.) In addition to providing best practices for structuring your code and automating tests, it also integrates a few companion libraries that really add power to an AngularJS project.

The tools from AngularUI team may even cure you from homesickness for jQuery plugins and jQueryUI. It seems to be working for me.

Here are some of the companion libraries that are worth getting intimate with.

  • AngularUI-Bootstrap – Twitter Bootstrap components written in AngularJS (included with ng-boilerplate)
  • AngularUI-Utils is a bunch of essential utilities (included with ng-boilerplate)
  • AngularUI – ports of many jQueryUI components
  • UI-Router will probably become a part of AngularJS core in the near future. You’ll want it if your application uses a nested navigation structure.
  • Restangular – a great way to simplify your JSON CRUD code.

Read Good Code

In addition to the libraries mentioned above, I will borrow, steal and plagiarize shamelessly (but respectfully and without breaking the law) from well-written projects. I encourage you to do the same. Let’s learn from smart people.

  • Angular-app, which I already mentioned – use it for examples of tests and client-server interaction
  • Built with AngularJS – holy smokes, a whole collection of good real-life projects, approved by AngularJS creators! You can’t beat that.

The AngularJS community seems to be growing very rapidly, and the culture is just unbelievable. People contribute open-source libraries, write documentation, share tricks and answer questions. It feels great to be a part of the AngularJS world.

Thank you for reading! Anything I missed? What do you do to be effective and stay sane in the JavaScript world?

TL;DR (but really, read the whole three articles – it’s worth it)

  • Use ng-boilerplate as a template for your projects.
  • Learn to use unit-testing and end-to-end testing with Angular, and make it your religion. Use testacular/karma and Jasmine. It will save you months and years of development. Use end-to-end tests in addition to unit tests. Borrow test practices from good AngularJS applications.
  • Acquire new Angular habits, and avoid old habits that do not translate into AngularJS world.

9 thoughts on “AngularJS Best Practices: I’ve Been Doing It Wrong! Part 3 of 3”.

  • […] AngularJS Best Practices: I've Been Doing It Wrong! Part 3 of 3 (artlogic.com) […]

  • Joskfg says:

    Good articles. I read the three parts in one shot.

  • Do any of the apps at builtwith.angularjs use ng-boilerplate? I poked around but didn’t find any.

  • DallonF says:

    “So, don’t start your app development with DOM or visual design. Instead, begin with application architecture. After you’ve decided what is it that your app does, and what data structures you’ll need for this, what logical parts will become controllers, you can design the views based on that.”

    For the love of all that is good in computing, DO NOT DO THIS. This is how every awful interface was born. Well, half of them, at least. The other half began with the words “wouldn’t it be cool if…?”

    For the sake of everyone who will ever use any UI you create, read these articles:
    http://www.uxdesignedge.com/2010/03/dont-design-like-a-programmer/
    http://www.uxdesignedge.com/2011/06/don%E2%80%99t-design-like-a-programmer-part-2/
    http://www.uxdesignedge.com/2011/11/don%E2%80%99t-design-like-a-programmer-part-3/

    • Andy Merskin says:

      I second Dallon’s response. UI/UX design is absolutely crucial before the development process. However, I think this little passage is being misunderstood.

      I think Vlad is referring to a process that should take place between design and the front-end development process. It’s important to structure your app’s functionality prior to hooking it up with the interface. Because an Angular app’s functionality is decoupled from the view itself, defining that functionality and writing tests for it will prove that it works and is independent from the view. You should not completely depend on your view for your app to “work” behind the scenes.

      While many would argue that in a lot of ways, Angular’s models and views are intertwined—your logic is still separate. So if you code out the front-end too soon (even if it’s based on beautiful, functional visual comps from a designer), it will be easy to forget that you’re writing the front end keeping the Angular approach in mind.

      I would argue that more experienced Angular developers could probably pull this off just fine because they are familiar with structuring their markup appropriately for their app. If you want to start off with your DOM layouts and visuals, go for it! But keep in mind that you may have a lot of HTML/CSS refactoring ahead of you as you begin writing the core functionality of your app.

      Thoughts?

  • MilosS says:

    What Dallon said

  • […] Three sanity-preserving ideas that will make me and you 10x more productive with real-world AngularJS applications This is the last in a three-part series on practical large-scale development with …  […]

  • […] AngularJS Best Practices: I’ve Been Doing It Wrong! Part 3 of 3 | […]

  • Leave a Reply

    Follow Art & Logic on Twitter

    Follow Our Blog via RSS

    RSS

    Connect Socially

    A&L on Facebook

    A&L on Google+

    Home   About   Blog   Careers   Contact

    %d bloggers like this: