Tag Archives: angularjs

Create configurable Angular services using providers

With Angular 2 on its way, it seems like a lot of developers are now afraid of Angular 1.x. I have nothing bad to say about Angular. Sure, some things could be made easier but that’s why Angular 2 is on its way. I’ve played with Angular 2 a bit, and it only works in Chrome. I’m fairly confident Angular 1.x will be around for quite a while.

In that light, let’s talk about creating configurable services. One reason why AngularJS is so popular is because you can easily create modular, reusable code. This code can encapsulate logic, directives, extensible services and factories (via decorators), as well as configurability. I’ll talk about creating directives and decorators in future articles.

This example will be a simple URL constructor for placekitten.com. Any AngularJS service can be written to be configurable (if there’s reason to configure the service, of course).

First of all, let’s see how this service will be used.

.controller('View1Ctrl', ['$scope', 'kittyService', function ($scope, kittyService) {
    $scope.kittycat = kittyService.getUrl();
}])
  <p>How about a kitty cat?</p>
  <p><img ng-src="{{kittycat}}"/></p>

Pretty simple. We’ll call kittyService.getUrl() and use the string returned from the service as the src for an image.

To create a configurable service, we’ll use an angular provider instead of a service or factory. The structure I use for a provider is this:

(function () {
    'use strict';
    var module = angular.module('myApp.services', []);

    module.provider('serviceName', function ServiceName() {
        // use `this` for configurable properties or functions

        this.$get = [function () {
            var service = {};
            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;
        }];
    });
})();

This structure is only a little different from a service or factory. Rather than return an object or constructor function, you use this.$get to create your reusable code. What you assign to this property is the array injector for your service definition. You’ll feel comfortable with this syntax if you define your services using the array-based dependency injection:

angular.module('myApp')
.service('serviceName', [function (){
            var service = {};
            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;
}]);

You can use instance properties and methods on the provider definition to configure your service, then use the private context of your provider to share the configuration with the service. Here’s the full code for the kittyService:

(function () {
    'use strict';
    var module = angular.module('myApp.services', []);

    module.provider('kittyService', function KittyServiceProvider() {
        var height = 100,
            width = 100;

        this.setHeight = function (h) {
            height = h;
        };
        this.setWidth = function (w) {
            width = w;
        };

        this.$get = [function () {
            var service = {};

            service.getUrl = function () {
                return 'http://placekitten.com/g/' + width + '/' + height;
            };

            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;
        }];
    });
})();

The provider has two private variables: height and width. The two methods on the provider object allow you to update these values, but only during the config phase. After your application’s config function has completed, your provider’s functions are no longer accessible.

One problem with this service is that placekitten.com shows the same image for a given combination of height and width. In the config phase of our application, the service’s height and width can be configured randomly:

.config(['kittyServiceProvider', function (kittyServiceProvider) {
    var widths = [200,300,400,500,600];
    var heights = [300,400,500,600,700];
    kittyServiceProvider.setHeight(heights[Math.floor(Math.random()*heights.length)]);
    kittyServiceProvider.setWidth(widths[Math.floor(Math.random()*widths.length)]);
}]);

The name injected into the config phase is kittyServiceProvider and not kittyService. This is important. AngularJS knows that when you request kittyServiceProvider in the config phase, you want the object containing your service definition (the KittyServiceProvider function in the example above). Once the config phase completes, the $injector service will prepare your service from the this.$get definition of your service.

If you load the example code, refresh the page a few times and you’ll receive a new kitty image.

NOTE: The heights and widths may not always combine in a way that retrieves an image. Just refresh for another example.

Why not do this in a service?

True, you could do this directly in the service if this was just your code. The benefit here is when you want to share a service with other developers, perhaps on a different project within your company or publicly on GitHub. What if your team wants a 200×300 kitty and HR wants a 500×500 kitty? In these situations you can’t just modify the code with your hard-coded values. True, in this example you could use constants or values instead but then your service would have a dependency on the consumer (this is bad).

A service that dumps a string for displaying a cat image is probably not that useful in the real world. Consider other possibilities. I’ve used providers for creating a reusable notification display which allows you to define whether a notification will automatically close and how long notifications will be displayed if they auto-close. Suppose your application often receives 40x errors when users leave their browsers unattended long enough for an authenticated session to time out; you could create a provider which caches failed requests and retries up to X (configurable) times before giving up. Or, you could create a configurable service which caches those failed requests, displays a login dialog, then automatically retries the failed requests X (configurable) milliseconds after logging in successfully. Those examples would require the use of an http interceptor, and would have been quite a bit more complex than a kitty image linker.

Code

Sample code for this blog post is available on github at jimschubert/blogs.

Further Reading

If you really want to dig into the guts of Providers (versus services, factories, constants, or values), check out Adrian Castillo’s blog post, AngularJS Providers under the hood.

For reference to each recipe, check out AngularJS Provider Recipes on the official docs.

Flattr this!

Decorating directives with isolate scope in Angular 1.3

A question from reddit excited my interest. Angular 1.3 apparently has broken the ability to decorate isolate scopes.

I tried version of Angular between the 1.2.26 known working version to the 1.3.0 broken version and found the issue was introduced in 1.3.0-rc.2.

The way to get around this is hacky:

app.config(function($provide) {
    $provide.decorator('mycustomDirective',['$delegate','$controller', function($delegate, $controller) {
        var directive = $delegate[0];
        directive.$$isolateBindings['othervar'] = {
          attrName: 'othervar',
          mode: '=',
          optional: true
        };
        
        return $delegate;  
    }]);
});   

Here’s a working example: http://plnkr.co/edit/CRxhX6?p=preview

Flattr this!

Manually debugging Angular scope

While a utility like Angular Batarang is invaluable, you’ll sometimes want to quickly and effectively inspect what exists on a given scope. If you’ve used Angular Batarang, you know that can be a pain in the ass. Here’s a quick alternative that works in Google Chrome, Firefox, and Safari.

Right-click on some element you want to inspect in your AngularJS-backed page. Select Inspect Element. This will open an ‘Elements’ inspector tab. Leave the element selected in that tab and go to ‘Console’. Type out the following:

angular.element($0).scope();

This will dump the scope to the console. You can assign this to a variable or navigate the parent/child scopes from here. This works because most browsers’ developer consoles support some extras in their Command Line API. The $0 refers to the most recently selected DOM element (try $0 through $4!).

You can test this out on the AngularJS Phone Catalog Tutorial. Here’s what you should see:

Android element debugging.

Flattr this!

Your First App: Node.js is complete!

I’m stoked to announce that I’ve finished writing my first self-published book, Your First App: node.js.

The book is a full-stack application development tutorial using what is commonly known as the ‘MEAN’ stack, but with a heavier focus on the backend technologies: node.js, express.js, and MongoDB. The book ends with a starter AngularJS project of an HTML5 instant messaging chat application.

While following along in the book, it may be useful to run test queries in a REST client. Postman is available for Google Chrome as a packaged application. Import `yfa-nodejs.postman_dump.json` (located in the root of the supplemental code’s repository) into Postman to evaluate the application’s API.

Check out the code on GitHub

Flattr this!

Your first app: Node.js (update)

I am currently writing a book called Your first app: Node.js. I am self-publishing this book through leanpub.com. You can check it out here.

One cool thing about self-publishing on leanpub is that people can purchase the book early and receive all future updates as I write. Feedback from this process may also help me to revisit areas I’ve unintentionally left a little light or not explained very well.

The book is currently about 66% completed. I recently completed the chapters through the node.js API. To complement that API, I will be writing a chapter on creating an AngularJS front-end. Then I’ll explain how to deploy your application to Digital Ocean (although the steps will be similar for many other hosts). Finally, I will provide some suggestions for further learning.

Below is the book description as shown on leanpub.

ABOUT THE BOOK

This book is intended for professionals or students who have a comfortable working knowledge of JavaScript, HTML, CSS, and the stateless nature of HTTP. If you’re not comfortable with JavaScript, I highly recommend reading both JavaScript: The Definitive Guide and JavaScript Garden. Although I’ll quickly go over some necessary fundamentals for beginners, it will be difficult to become a ‘node.js developer’ without a solid foundation in JavaScript. HTML, CSS, and client-side JavaScript will be necessary for the presentation of your application, while understanding the stateless nature of HTTP will make some of the techniques discussed in this book easier to learn.

Why this book?

Many books on a given technology focus on really digging into a certain framework or a few simple concepts. Node.js is an interesting technology for many reasons, including:

  • it popularized server-side JavaScript
  • encourages modularization
  • has a fairly large community
  • provides amazing throughput for data

I have read many technology books and yet I’ve always felt like there was a gap between books covering a given technology and how you’d actually undertake creating a full application on your own. When I realized that node.js is attracting a lot of front-end developers and hobbyists to the community, I understood what that missing “gap” was: the application life cycle. For developers without a degree in Computer Science or Information Systems, it may be difficult to figure out how to actually start creating a full application. I hope to address this in the text by providing some simple guidelines that help to lay out a clear path between the starting point and the finished product. The intended audience for this book is anyone familiar with HTML, CSS and JavaScript. You don’t need to be a professional engineer or even have years of experience. In early chapters, I discuss the aspects of JavaScript that I feel are crucial to understanding how to write an application in node.js.  Where I feel newer developers may benefit from further reading, I suggest online or print resources that I’ve found helpful.

What makes this book different?

When working with Junior developers, I try to avoid the sink or swim mentality that many Seniors seem to have.  Instead, I like to explain why I’ve chosen one thing over another. In this book, I include an entire chapter to discuss development considerations which are usually omitted from mainstream texts.  For instance, when was the last time you read a book that suggested a build automation tool? I can’t remember any book that clearly explained why a sample application was written to use MongoDB instead of Redis or MySQL. These are things I attempt to cover in this book before diving in to the meat of the text you’d find in similar books. I even have a short prototyping chapter for readers who are unfamiliar with the technologies used in the book to try some hands-on code before applying this knowledge to the sample application.

These are all things people with professional full-stack (e.g. client-server-database) experience do on a regular basis. With such a fresh, young community being attracted to node.js application development (many without server-side or database experience) I think this book’s early focus on process and maintainability are important aspects for any beginner to pick up.

Technologies

Writing an application requires a developer to pick up skills in multiple technologies for frameworks. I plan to at least cover the basics of all the tools necessary to create a full node.js application. Some of the technologies covered in this book are:

  • express.js (node.js)
  • grunt.js (node.js)
  • mocha (node.js)
  • Twitter’s Bootstrap (CSS)
  • angular.js (client JavaScript)
  • MongoDB (database)
  • git (source control)

The intention is not to fully teach a developer everything about every one of these technologies, but I will go over the basics for everything that is not considered node.js and go over the node.js technologies in greater detail.

Planned Chapters

Future chapters will focus on:

  • ✓ git workflow
  • ✓ project structure and setup
  • ✓ setting up a database
  • ✓ modeling a database “schema”
  • ✓ creating a minimal API
  • creating a front-end application
  • asynchronous communication between client and server
  • ✓ authentication strategies
  • … more

As this book is written, I welcome your feedback and comments at nodejs@ipreferjim.com

Status

This book is currently about 66% complete.

The final product is estimated to be between 200 and 250 pages in length (not including appendices).

Sample Code

Sample code for this book is located on github at jimschubert/yfa-nodejs-code.

Flattr this!

Release: New Tab Redirect 3.0

On Wednesday, I began the rollout of New Tab Redirect 3.0 with some bug fixes and a huge new feature: a built in ‘Apps’ page.

Preface for Searchers

By 9pm of release day for New Tab Redirect 3.0, I lost all faith in humanity. I’m a professional software engineer, so I realize users want what they want and if you can’t or don’t give it to them they get really bitchy. But, New Tab Redirect is free software so I technically have nobody to answer to. I’m a human and I make mistakes. I rolled out to 50% of users and forgot to add an explanation of the permissions changes to the description on the web store and to the wiki. Luckily, one user submitted an issue and another emailed me. That’s two users out of 750,000/2 users.

For anyone looking for an explanation of the new permissions, I’ve explained it on the wiki. If you read the explanation and still don’t agree with the added permissions, use another extension… it’s that simple. Don’t be a jerk and call me names or suggest that I’m doing something illegal with no grounds for such defamation. I have no respect for people who intentionally hurt others. One person went as far as to say I had a huge ego; really… I don’t see how giving people something for free and continuously improving and maintaining it for 5 years means I have a huge ego. But, whatever. The rest of this post is about some awesome technical stuff in the new version, namely the New Tab Redirect ‘Apps’ page.

Why a new version?

When Chrome 33 removed chrome-internal://newtab (which pointed to the ‘good’ New Tab Page), I realized that I could create something that I actually wanted personally, while at the same time fixing the whole ‘address bar does not focus’ problem all users targeting chrome://apps were having. Because New Tab Redirect actually redirects to the user’s optional URL, the focus that Chrome gives to New Tab override pages gets lost. That’s just how it is. I’ve documented workarounds on the extension’s wiki.

Another reason for the new version is because Google is cracking down on extensions. Extensions must now have a single visible UI. In other words, although New Tab Redirect 2.2 opened a welcome page and provided an options page, there was no user interface. It was a ‘New Tab Override’ page that didn’t directly offer an override of the new tab page. In other words, there was no default override on installation. I fixed that by creating the override page I wanted by default (I used chrome-internal://newtab). Doing this also meant I would get 5-10 less emails each week from users saying “I use chrome://apps, but I wish the address bar would focus so I could search just like the old new tab page”. Done and done.

Technology: AngularJS

At work, we’ve been using AngularJS on a new project. I’m really loving it. I decided to use AngularJS for the New Tab Redirect ‘Apps’ page because it would mean minimal, reusable code with a clean structure that my users could read and understand.

AngularJS is really web development for engineers. Normal JavaScript is often written with all kinds of haphazardly-structure files, crazy include structures, and continuation passing style causing ridiculously nested functions and hard to read code. AngularJS offers a clean modular structure with a service locator, dependency injection, and the ability to declaratively extend HTML.

The main parts of AngularJS are:

Services

Singletons that provide some shared functionality. A Singleton means there will be one instance of an object in the application a time. An interesting thing about services in AngularJS is that you can actually create factories with static data via services.

Factories

Factories are like services, except they’re meant to represent something that is created anew every time it is injected into a controller.

Controllers

Controllers are blocks of code meant to be tied directly to blocks of the DOM (either directly, via routes, or via directives).

Directives

Directives are constructs in AngularJS that allow you to define new HTML elements or attributes that can be applied at runtime to existing elements.

Scope

Probably the hardest part of AngularJS to grasp is the concept of ‘scope’. It’s not the same as JavaScript scope. In AngularJS, scope can be considered the same as the model in the MVC pattern; it’s bound to the view via the controller. AngularJS does dirty checking on the scope to incorporate two-way binding. That just means changes in the DOM to scope-bound properties will immediately be available in the controller, while changes in the controller that are done within an angular digest get updated in the DOM. Generally, there’s no need for manually binding event listeners.

If you want to learn more about AngularJS, the tutorial on angularjs.org is an excellent place to start.

Technology: Chrome Extension APIs

Chrome JavaScript APIs for extensions are really a pain in the ass. In order to use functionality, extensions must ask for permissions. However, Google doesn’t offer read-only permissions. This caused a lot of contention in the permissions request for New Tab Redirect 3.0. If you’re writing an extension and you plan to add some functionality that requires a permission that says ‘Read and modify’, my suggestion is that you don’t add that feature.

In order to create an ‘Apps’ page that somewhat resembled the old New Tab page, I needed:

  • bookmarks (permission: bookmarks, Read and modify your bookmarks)
  • Most Visited Sites (permission: topsites, Read and modify your browsing history.. yeah the description is stupid)
  • Apps management (permission: management, Manage your apps, extensions, and themes)
  • chrome://favicon/ (no permissions needed)

The permissions I needed were only:

  • pulling up to 40 bookmarks from the bookmarks bar only
  • querying top sites (the API call only gives you 20 sites, why describe it as Read and modify your browsing history?)
  • apps management, not extensions and not themes

I can only imaging that Google has a hard enough time as a company, considering how they’ve dropped quite a few products that I loved. They’ve also invested a lot of time in technologies like Google Glass and cars that can drive themselves. They’re likely not at all interested in making a more robust permissions system for extension developers.

The permissions required for the New Tab Redirect ‘Apps’ page are what they are. So many users got scared and even went as far as to falsely accuse me of anonymously collecting their data. The extension is open source, so accuse away: you’re completely wrong. Then again, people that use Google Chrome and think Google is not stealing gobs and gobs of their data are ignorant to the many mechanisms built into Chrome specifically to steal their data. Consider the data stored at chrome://predictors/: if Google has 1 billion Chrome users, they can now collect data from 1 billion distributed machines that tells them what users type into the address bar and where that user ends up navigating. Extension developers are the least of your worries (like you, I don’t trust extension developers either).

The code, a brief walkthrough

New Tab Redirect previously loaded redirect.js, which simply redirected to a page defined on the options page. I wanted to keep this functionality, but at the same time I did not want the New Tab Redirect ‘Apps’ page to start loading if the user defiend an optional redirect.

app.js

AngularJS makes that easy. You can provide a flag to defer bootstrapping of the application until you explicitly tell angular ‘Go!’:

window.name = 'NG_DEFER_BOOTSTRAP!';

This just has to be declared before you call angular.run(). Then, when you’re ready, you call:

angular.resumeBootstrap();

Then, angular will begin wiring itself up to the page. In this way, the new ‘Apps’ page DOES NOT LOAD unless the user is using that page.

One interesting hurdle when writing an AngularJS application for Google Chrome Extensions is that AngularJS wraps some standard HTML elements like a, input, img, and form. I’m only using anchor tags and images in New Tab Redirect, but I didn’t undrestand why images for Apps wouldn’t load. The problem is that for images, you have to whitelist the chrome protocol, and for anchor hrefs you need to whitelist chrome-extension so the AngularJS compiler will be happy with the rendered HTML. This all gives the following clean app.js:

'use strict';
// Setting the window.name property in this way allows us to call app.run(), but block until it's ready to be resumed.
// the resume happens in redirect.js if no redirected new tab url has been specified.
window.name = 'NG_DEFER_BOOTSTRAP!';
var app = angular.module('newTab', ['newTab.controllers', 'newTab.directives', 'newTab.filters']);

app.config(['$compileProvider', function($compileProvider) {
    // see https://github.com/angular/angular.js/issues/3889
    $compileProvider.imgSrcSanitizationWhitelist(/^\s*(https?|ftp|file|blob|chrome):|data:image\//);
    $compileProvider.aHrefSanitizationWhitelist(/^\s*(https?|ftp|mailto|tel|file|chrome|chrome-extension):/);
}]);

app.run();

controllers.js

The new ‘Apps’ page has a single controller on the main page. When it loads, it checks for the user’s synced preferences, then loads apps followed by bookmarks and top sites only if the user wants to load them. The cool thing about AngularJS is how clean doing this becomes (I’ve removed function logic below for brevity full file here):

'use strict';
var controllers = angular.module('newTab.controllers', ['newTab.services']);

controllers.controller('MainController', ['$scope', 'Apps', function ($scope, Apps){
    var enable_top_key = 'ntr.enable_top',
        enable_bookmarks_key = 'ntr.enable_bookmarks',
        bookmarks_count_key = 'ntr.bookmark_count',
        top_count_key = 'ntr.top_count';

    $scope.extension_name = "New Tab Redirect!";
    $scope.enable_bookmarks = false;
    $scope.enable_top = false;
    $scope.bookmarks = [];
    $scope.show_prefs = false;
    $scope.bookmark_count = 10;
    $scope.top_count = 10;

    $scope.save_preferences = function(){ };

    function loadBookmarks() { }
    function loadTopSites() { }
    function loadApps() { }

    $scope.$on('UninstalledApp', loadApps);

    // initial page setup
    var querySettings = [enable_top_key, enable_bookmarks_key, bookmarks_count_key, top_count_key];
    Apps.getSetting(querySettings)
        .then(function(settings){
            // assign settings to scope
        })
        .then(function(){
            loadApps()
                .then(function(){
                    loadBookmarks();
                    loadTopSites();
                });
        })
        .then(function setupWatches(){
            $scope.$watch('bookmark_count', loadBookmarks);
            $scope.$watch('top_count', loadTopSites);
        });
}]);

When you declare a Controller, you can pass just a function as the second parameter and the parameter names will tell AngularJS how to look up services, factories, or other injectables so they’re available in your controller. Another way to do this is as I’ve done it and pass an array where the beginning of the array are the names of the dependencies and the last element of the array is the function of the Controller. This style allows you to later minify code without breaking AngularJS’s dependency injector.

You’ll notice here that Apps.getSetting is a Promise. Promises make code way cleaner. The way the getSetting promise is setup here allows me to set all settings to their properties on the scope, then load apps (always done), then conditionally load bookmarks and top sites. After everything is loaded, a $scope.$watch call allows us to say that anytime bookmark_count or top_count changes, call the relevant function again. If I had bound these watch functions anytime before in this promise chain, these functions would be called multiple times. Each function simply delegates to the Apps service call and returns a function, so that code is omitted from the above logic.

services.js

The services file actually contains a single service, Apps. The service has the following interface:

{
    getAll: function () { },

    launch: function(id){ },

    pinned: function(url){ },

    newWindow: function(url){ },

    uninstall: function(id){ },

    tab: function(url){ },

    navigate: function(url){ },

    topSites: function(){ },

    saveSetting: function(obj){ },

    getSetting: function(obj) { },

    getBookmarksBar: function(limit){}
};

A better design interface would have probably been to create a service facade around the ‘Tabs functionality (pinned, newWindow, tab) and the Config functionality (saveSetting, getSetting). To keep it simple I used only ‘Apps’.

Each of these functions returns a promise to allow for clean chaining of asynchronous functions.

Rather than explain each function in depth, I’ll cover just the first one and you can look at the others on GitHub.

Apps.getAll() will retrieve all apps using the chrome.management.getAll API call provided by chrome:

getAll: function () {
    var deferred = $q.defer();

    chrome.management.getAll(function (results) {
        $rootScope.$apply(function(){
            deferred.resolve(results);
        });
    });

    return deferred.promise;
},

The problem here is that AngularJS is only aware of changes on the scope that occur during the digest loop by explicitly applying ‘regular JavaScript’ to the AngularJS internals. This is done with $rootScope.$apply whenever you have some data that you want AngularJS to consider. Chrome doesn’t provide error callbacks on the API because errors are handled within the browser, making it easy for client applications like this to handle logic. A ‘deferred’, created by $q.defer(); is how JavaScript code can promise a future value to callers and is not AngularJS-specific; jquery has deferreds, Kris Kowal has an excellent Promises implementation called q, and versions of the CommonJS Promises proposal is implemented in many other frameworks or utilities.

A deferred object has two states: success and failure. To trigger the success state of a deferred object (which completes the promise successfully), you would call deferred.resolve. To initiate an error, you’d call deferred.reject. You can chain promises by returning a new promise from a chainable function, usually .then(fn).

HTML

I’m going to cheat a little here and show you the HTML before the directives. I’ll only show two snippets of HTML: one contained in main.html and a template.

In main.html you’ll see:

<div class="container app-container clear" ng-class="{'after-bookmarks': enable_bookmarks && bookmarks.length > 0,'populated':apps.length > 0}">
    <div><input type="search" ng-model="q.name" ng-show="apps.length > 5" placeholder="Filter apps"></div>
    <chrome-app ng-repeat="app in (apps | filter:q)" app="app"></chrome-app>
    <div ng-show="(apps | filter:q).length == 0" style="margin:1.5em">No matches found.</div>
    <span class="clear"></span>
</div>

This actually has a lot of AngularJS stuff in it. The opening div tag has this weird ng-class attribute in which the content looks like a JSON object. This is one of many built-in AngularJS directives. It applies the class ‘after-bookmarks’ based on the condition in the value of the property at runtime (during a digest loop). This means that any time enable_bookmarks changes, the classList might change from “container app-container clear” to “container app-container clear after-bookmarks”. If the ‘populated’ condition later changes, we’d have “container app-container clear after-bookmarks populated”. Then, the user could disable the bookmarks setting and AngularJS would automatically update the classList to “container app-container clear populated”. There’s no additional work you need to do.

Next, there’s an input type="search" that has an ng-model and ng-show attribute. Usually, something applied to ng-model will represent a property on your $scope object. So, if you had ng-model="favorite.color", and in your controller, you’ve set $scope.favorite = { color: 'blue' }, the value of the text box would read ‘blue’. If you changed the input text from ‘blue’ to ‘red’, you would immediately have the true condition in your controller $scope.favorite.color === 'red'. The ng-show toggles the display:none style of the element based on the condition.

Next, there’s this weird non-standard XML element, <chrome-app ng-repeat="app in (apps | filter:q)" app="app"></chrome-app>. That’s a directive I’ve defined and will discuss later. The attribute, ng-repeat acts as a foreach loop. The value of that attribute says for each value in apps | filter:q, apply app to the ‘app’ attribute of my custom directive, and generate the templated structure. The apps | filter:q syntax is how AngularJS declaratively applies filters (another available application module like a service or factory). The | is what actually applies the filter, the filter:q is how we define what filter to call and what parameter to pass the filter. In standard JavaScript, this might look like:

var apps = [];
var filtered = apps.filter( function filter(q) {
    // filter:q logic here.
});

In AngularJS, the filter filter is way more involved.

The <chrome-app></chrome-app> directive will take the ‘app’ object assigned to the ‘app’ attribute (app="app") and apply it to the following template:

<div class="app-icon">
    <a href="app.appLaunchUrl" chrome-launch="app.id" chrome-type="app.type" class="app-icon-128">
        <img src="{{app.icons|iconsize:128:app}}" title="{{app.name}}"/>
        <span class="app-desc">{{app.name}}</span>
    </a>

    <div class="app-actions">
        <a href="app.appLaunchUrl" ng-if="app.type != 'packaged_app'" chrome-pinned="app.id"
           title="Open {{app.name}} in a pinned tab"><i class="fa fa-2x fa-thumb-tack"></i></a>
        <a href="app.appLaunchUrl" ng-if="app.type != 'packaged_app'" chrome-new-tab="app.id"
           title="Open {{app.name}} in a new tab"><i class="fa fa-2x fa-level-up"></i></a>
        <a href="app.appLaunchUrl" ng-if="app.type != 'packaged_app'" chrome-new-window="app.id"
           title="Open {{app.name}} in a new window"><i class="fa fa-2x fa-external-link"></i></a>
        <a href="app.optionsUrl" chrome-options="app.id" ng-if="app.optionsUrl" title="Open options for {{app.name}}"><i
                class="fa fa-2x fa-wrench"></i></a>
        <a href="#" chrome-uninstall="app.id" title="Uninstall {{app.name}}"><i class="fa fa-2x fa-trash-o"></i></a>
    </div>
</div>

The app object is the result object from chrome’s API call.

The new thing in this snippet is the introduction of {{ somePropertyName }}. This is an interpolation in AngularJS. It’s actually not that performant a lot of the time, but for something like title="{{app.name}}" it is usually the only way to dynamically set string contents. Here you see another AngularJS directive, ng-if, which conditionally adds to or removes from the DOM the whole element it’s applied to. Then, you see other custom directives, chrome-pinned, chrome-new-tab, chrome-new-window.

With these examples, you now can understand probably 75% of the code you’d find in AngularJS

directives.js

The last bit to cover is directives. This is my favorite aspect of AngularJS so I’ll try really hard not to ramble on the topic.

AngularJS lets you define directives to run for any attributes, elements, or CSS class names. I don’t generally use the class feature. Directives allow you to hook into the compile phase or the link phase (but not both simultaneously). You can also define a controller or explicitly create a child scope or isolated scope for the given element(s). I like to keep things simple and stick to adding functionality in the link phase.

Here’s an example:

directives.directive('chromePinned', ['$log', 'Apps', function($log, Apps){
    return {
        // attribute only
        restrict: 'A',

        scope: {
            id: '=chromePinned',
            url: '=href'
        },

        link: function($scope, $element, $attrs) {
            if($scope.id){
                $element.bind('click', function(e){
                    e.preventDefault();
                    Apps.pinned($scope.url)
                        .then(function(tab){
                            $log.debug("Opened app id %s in pinned tab #%d", $scope.id, tab.id);
                        });
                });
            }
        }
    };
}]);

The directive here is declared in the same dependency injection style as the controller, where we define the dependency names and function in an array to prevent breaking the injector if the code is ever minified. The directive must return and object that represents a directive definition.

This directive is restricted to only work on attributes (however, restrict:'AEC' would work on attributes, elements, and class names). Defining an object for the scope property creates an isolated scope where id is data-bound to the property of chromePinned (in attribute format it is chrome-pinned‘s value) and url is bound to href. Isolated scopes break the directive out of the scope hierarchy that AngularJS maintains by default. Isolated scopes can take some getting used to, but I think they’re safer and easier to follow.

The linking function binds a click event to the element (e.g. an anchor tag of <a href="#" chrome-pinned="12345">). Any on click, we call Apps.pinned with the url defined by the anchor’s href attribute. Whenever you work on an element in a linking function, you’re working in standard JavaScript (i.e. outside of AngularJS’s digest). You should always call $scope.$apply with whatever function you want to make AngularJS aware of. In this directive, you don’t see that call to apply because it’s done within the service itself.

Conclusion

In all, the new feature was quick and painless to code. The files are clean, easy to read, and well organized.

The code, as always is on github: jimschubert/NewTab-Redirect

Flattr this!

Karma error: RangeError: Maximum call stack size exceeded

I’ve been working on a bootstrap application for express.js, angular.js, and bootstrap. The idea being that I can provide a boilerplate for quick prototyping of applications.

I was having some issues setting up karma, the test running used by angular.js. I was receiving an error:

...
	
INFO [Chrome 28.0 (Linux)]: Connected on socket id 2uhtx5qf6HDM8_A1qssQ
INFO [karma]: Delaying execution, these browsers are not ready: Chrome 28.0 (Linux)
Chrome 28.0 (Linux) controllers should .... FAILED
	RangeError: Maximum call stack size exceeded
	    at String.match (native)
	    at Object.b.event.remove (/home/jim/projects/express-angular-bootstrap-boiler/src/public/javascripts/vendor/jquery-1.9.1.min.js:3:25827)

...

I messed around with the file includes for a while, then Googled a bit for any possible issues.

It turns out that I was using bootstrap v 2.3.0, which appears to have issues with jQuery 1.9.1 as reported in this issue.

As noted in the issue, upgrading to a newer version of Twitter’s Bootstrap (2.3.2) resolved the issue.

Flattr this!