5 AngularJS Power Features that are awesome in non-trivial webapps

I’ve been developing AngularJS webapps in production environments since June last year. My experience have been awesome, redefining my understanding of front-end development and in the process, turning myself into an adept of JavaScript. There are many JavaScript frameworks out there, and choosing the right one might be tricky, but the Internet has no lack of tutorials, reviews, comparison charts and even a handy To-Do app written in several frameworks. So I don’t think we need yet another blog posts listing AngularJS features. Rather, in this article I want to share a bit of my experience with AngularJS, and letting you know 5 very “angularish” features that have changed the way I program webapps in non-trivial, commercial, high-performance environments.

Two-way data binding

AngularJS provides two-way data binding out of the box, and it’s one of the AngularJS features with the highest wow factor, specially since you can use it right away and very easily. Two-way data binding is not only eye candy but it’s really what modern webapps are about: real-time. As pretty much with desktop applications, a modern webapp should no longer wait for the user to click on a “apply” or “save” button to see her changes reflected in the UI.

Angular two-way data binding also permanently binds the view and your models, no longer requiring refresh cycles, which programatically may be prone to bugs or simply need a lot of redundant and hard to maintain render code (I’m looking at you BackboneJS)

Directives

Directives are basically a way to declare a new HTML tag or attribute and make it do whatever you want. First, recall your definition of HTML: a markup language, it’s declarative by it’s own nature, meaning that if you write something like

The browser will render it as a clickable text “My Site” that when clicked, will point the browser to the address referenced in the ‘href’ attribute.  The browser knows all these tags and attributes and how to represent them in the UI; declarative markup it’s a simple idea it’s the foundation of the web. The downside is that you cannot declare new elements…well, this is where AngularJS comes to the rescue. By using directives, you can teach the browser to learn new tricks.

So thanks to AngularJS, you could write in your HTML

<my-element>Something here</my-element>

Use your new element <my-element> anywhere and make it do whatever you want. For example, flash the text “Something here” every 5 seconds and fade it with all the colors of the rainbow. A more serious and useful example of a directive might be something like this: create a new element to make a piece of text editable in-place. So ideally:

Writing the proper directive, I can make editable any element enclosed between <editable> tags, and bind it to the model indicated in the model attribute. So an example here

Directives are extremely powerful. It feels like HTML 6. They’re reusable and goddamned modular. In my example app, see how even I included a ng-enter directives, which closes the edit box. The fun thing is that ng-enter directive is used within another directive!. It’s simply awesome.

Watchers

Who watch the watchmen? In modern web applications, very usually you need to keep track of changes performed on models. One usual way to solve this problem would be to create a getter/setter functions to a model, and trigger an event or message whenever the model is changed through it’s setter. However, due to the dinamic nature of JavaScript, it’s possible that somebody changes your model without accesing its setter, or even more, what if you have many UIs that might change the value of a variable, or such variable might be modified due an event or service call? This can easily turn into a nightmare. But AngularJS will allow us to set watchers on models. This is even more awesome if you consider that unlike many other frameworks, in AngularJS your models are plain JavaScript objects, not extending from a Model class of any sort (for example, in EmberJS App.Person = DS.Model.extend(); )

So, if you want to monitor any variable within any scope, you simply use something like

Broadcast and Listeners

The observer design pattern is, oddly, seldom used in web applications. Or at least in my experience, I haven’t seen it implemented in many places, but I think that the web offers a lot of ground to explode this pattern. For example suppose you create a two-player chess webapp. You write a notification system that fires the event “UserHasMadeAMove” and in the first release of your site, the only thing listening to that notification is your alerts section in your navbar. But as your application improves, you want many elements or components of your application to listen whenever “UserHasMadeAMove” fires, AND you don’t want to register a new listener every time you add a new interface. So for instance in your chess app, besides adding a notification in your navbar, you also want the background to flash, to active a “make a move” button for the opposite player, or even play a sound. All these components can simply be listening to the broadcasted “UserHasMadeAMove” message like this

The broadcaster itself comes in two flavors: broadcast and emit. They’re pretty similar and the only difference is that broadcast notifies downwards to all child scopes, and emit notifies upwards through the scope hierarchy.

Real HTML templates

There’s a boom of rendering and templating engines as well, and they seem beyond count! But take a minute and think, what’s the point of a template engine anyway? It wasn’t the browser itself responsible for rendering things in first place? Exactly! AngularJS does not rely on any rendering engine. It actually uses browser-parsable HTML and .html files for its partials. I’m going to simply leave here the explanation provided by AngularJS official site:

  • Others - Most templating systems begin as an HTML string with special templating markup. Often the template markup breaks the HTML syntax which means that the template can not be edited by an HTML editor. The template string is then parsed by the template engine, and merged with the data. The result of the merge is an HTML string. The HTML string is then written to the browser using the.innerHTML, which causes the browser to render the HTML. When the model changes the whole process needs to be repeated. The granularity of the template is the granularity of the DOM updates. The key here is that the templating system manipulates strings.
  • Angular - Angular is different, since its templating system works on DOM objects not on strings. The template is still written in an HTML string, but it is HTML (not HTML with template sprinkled in.) The browser parses the HTML into the DOM, and the DOM becomes the input to the template engine known as the compiler. The compiler looks for directives which in turn set up watches on the model. The result is a continuously updating view which does not need template model re-merging. Your model becomes the single source-of-truth for your view.

As a developer, this represents an advantage not just because you don’t need to include yet another library to parse templates but because the compiler component is quite powerful combined with your own directives, to compile and modify the DOM before binding it with any scope (your models). The result are very fast and flexible views. A demonstration of this magic is that you can even write mini apps only with views! Not even controller or models explicit declaration. Take a look at:

  • maxsurguy

    This is beautiful. I love how simple it is to make things spring to life with Angular. Need to learn more though, switching from backbone has proven to be difficult for me so far…

  • http://www.odiseo.net/ odiseo42

    Angular has very unique features and philosophy which set it apart from other frameworks, and the result is that you have to get used your mind to the “angular way”. For example, its declarative nature. e.g. ng-click=”doSomething()”, avoidance of DOM manipulation in controllers, directives (which I believe are unique to angular), etc.
    All these are the result of AngularJS philosophy of seeing HTML and JavaScript as something that should be extended, rather than fixed (as most frameworks attempt). As a definition I saw: “AngularJS is what HTML and JavaScript would look like if they were made for modern-day web applications”.
    I encourage you to keep learning AngularJS as this picture shows http://www.bennadel.com/resources/uploads/2013/feelings_about_angularjs_over_time.png

    Thanks for stopping by.