This video is the recording of my presentation at the September 2013 DFW Area AngularJS Meetup Group on AngularJS Forms Validation.
This video is the recording of my presentation at the September 2013 DFW Area AngularJS Meetup Group on AngularJS Forms Validation.
Hailing All Frequencies! Is anybody out there? This is the USS AngularJS, we have a problem our services are speaking in Klingon and our controllers can’t communicate with their Ferengi directives. Can anyone help us!
I don’t know how many times I’ve seen a question about what is the best way to communicate between components in AngularJS. A lot of the time the resulting answer is to use the $rootScope object to $broadcast a message to anyone who might be listening for it. But, that really isn’t the best way to do it. Broadcasting messages between components means that they need to know too much about how things are coded reducing their modularity and re-use.
In this article I show you how to use the Pub/Sub Design Pattern for inter-component communications in AngularJS.
So you are probably really jazzed about the addition of the new directive to the angularjs-localizationservice project and the fixes to help improve it’s performance. But, now that you are probably using the project I bet you are probably saying the same thing my devs and designers were saying, “Hey Jim, this new directive really works great, but how do we do translations for placeholders and titles?”
Well, this post is going to cover a new directive that’s been added to the project just to handle such things.
In my previous article on Localization, Localizing Your AngularJS App, I provided a simple service and filter that allows you to provide language translations based on a translation file. Initially this worked for about 50% of our transalation needs, however once we started looking at the overall performance of our AngualrJS App it was apparent that I needed to tweak things a bit.
In my previous post Using Response Interceptors to Show and Hide a Loading Widget I showed how to display a loading widget whenever an Ajax request started and hide it when all the requests completed by using a $http resource interceptor.
Unfortunately, I violated one of the core tenets of AngularJS’ best practices by modifying the DOM outside of a directive. I want to thank everyone who brought that to my attention and provided examples on how to clean up the code.
This post will walk through the revised code to show how to do it properly. I will also provide a second solution, that I think is even better structured, that uses a Publish/Subscribe pattern to encapsulate the whole messaging solution and keep the publishers and subscribers from having to know anything about the notification mechanism.
AngularJS provides extension points which allow you to intercept responses to http requests before they are handed over to the application code. You can use these extension points to provide global exception handling, authentication, or any other type of pre-processing you might need in your app. In this article I’m going to show you how you can use a response interceptor to turn a loading widget on and off as your http requests are made and completed.
If you’ve spent some time writing services in AngularJS that front-end Web APIs, you have probably used the $http service. One of the prevalent code patterns that tends to develop involves calling the .then() method on the promise that is returned from the various $http methods. This in effect waits to execute code until the asynchronous request returns and the promise is resolved.
The more complicated the Web API you are interacting with, the more your controller code tends to end up with several bits of code as shown below:
user.requestCurrentUser().then(function() { $scope.currentUser = user.getCurrentUser(); });
Testing this code can be a bit problemsome for newcomers to AngularJS. This article shows a simple way to mock your services to provide similar functionality so you can unit test your controllers that contain these type of code patterns.
I am sure many of you reading this come from an ASP.NET background or are familiar with how ASP.NET web apps work with the constant post back to the server to update data, process it and redirect the user to the next step of the process. It has worked for the past 10 years and it has worked well. But, there are better ways to interact with the server and update the user.
The growth of JavaScript, jQuery and frameworks such as Backbone, Knockout, and Ember have done an enormous amount for improving client side interaction and asynchronous communications with the business logic back-end.
That is where the app I’m maintaining is, we use ASP.NET REST based services with jQuery to manage user interaction and communicate with the back end. It works and its performance is OK, but it’s not great and it really doesn’t take advantage of today’s browser capabilities.
If you plan on being in the Web App development business for any amount of time, sooner or later you are going to be faced with building an app that supports multiple languages. When this time comes you’ll be faced with the localization challenge that so many developers before you have faced.
To solve this challenge some developers have built entire localization frameworks and libraries, while others have resorted to re-creating their entire site in the desired language and redirecting users based on their browser culture.
In this article, I’ll show you an easy way to use an AngularJS Service and Filter to pull localized strings from a resource file and populate the page content based on the user’s browser culture.
One of the core features of AngularJS is the ability to extend the HTML Syntax with directives. Directives allow you to componentize segments of HTML into a single tag that can be re-used throughout your AngularJS app. So instead of repeating the following HTML all over your code:
<div class="row-fluid" ng-repeat="adjunct in adjuncts | filter:search | orderBy:'name'"> <div class="span1">{{adjunct.Name}}</div> <div class="span1">{{adjunct.Type}}</div> <div class="span1">{{adjunct.Use}}</div> <div class="span1">{{adjunct.Time}}</div> <div class="span1">{{adjunct.Amount}}</div> <div class="span1">{{adjunct.UseFor}}</div> <div class="span1">{{adjunct.Notes}}</div> <div><a href="#/editadjunct/{{adjunct._id.$oid}}"><i class="icon-pencil"></i></a></div> </div>
With a directive you can use the following HTML:
<div data-display-adjunct class="row-fluid" ng-repeat="adjunct in adjuncts | filter:search | orderBy:'name'">
Now anywhere where you would use the above HTML, you can use the directive instead and be consistent across you entire site. This also saves you time when changes are required. If the amount of data that needs to be displayed changes you only need to update the directive and your done. You don’t have to hunt around your HTML files looking for every occurrence to change.
Directives allow you to not only specify what data from your app to bind to, but they can also handle the work of transforming the data into different formats, removing that responsibility from your controller, helping you to keep to the single responsibility principle.
If you apply this simple principle on bigger scales, directives can be used to build rich components that bind to your app’s data and reduce the amount of HTML you need to create across your entire site.
In this article, I’m going to show you how to write a simple directive that generates an image tag with a user’s avatar from the Gravatar site, http://en.gravatar.com/