Entries Tagged as 'AngularJS'

Recently I've been playing around with the current beta distribution (0.8.3) of Angular Material Design:
a set of Angular modules and resources that apply the "Material Design"
style and behaviors used in Android 5.0 to an Angular website.

One of the services added by the Angular Material modules is the $mdToast service,
which provides an easy way to display small pop-up notifications
("toasts") in response to events (a common behavioral convention on
mobile devices). I wanted to use the $mdToast service in my httpInterceptor
service function for handling HTTP response errors so that I could
display a toast message if the server returned a nasty 500 HTTP status
code.

But I ran into a problem: when I tried to inject $mdToast into my
interceptor service factory using standard Angular dependency injection,
I got a "circular dependency found" error message when I loaded my
Angular app. The same thing happened when I tried injecting $mdToast
into a service module of my own creation - toastService - and injecting
that into my interceptor service factory.

In Angular 1.x, the run() method of a module behaves similar to the main method or constructor method concept found in other languages: it's a method that runs as soon as all of the dependencies have been resovled and the module has been configured.

Because of this, even if you use run() to execute a named method that can be called separately in your unit test, the code in that method gets executed during the process of instantiating the module to use in your tests. That makes it difficult to do any testing that compares the state of data prior to running the method or tests that require mocking dependencies and dependency behavior inside of the method.

So when I ran into this problem, I came up with a mild "hack" to work around the immediate execution of the run() method. I made the execution of the code inside my run method dependent on the value of a Boolean constant:

Suppose for a moment that you have an AngularJS single-page
application, one with view routes managed with then ngRoute module, that
is used by users with different roles. A user in your company's Sales
group has access to certain areas of the application, while a user in
Accounting works in other parts of the application. And there are also
some areas of the application that are common to all users.

Now, you already have the navigation menu wired up so that users only
see the navigation links appropriate to their user roles. And even if a
Sales user somehow ends up in a view meant for an Accounting user, the
server answering the REST calls for the data powering that view is going
to check the security token sent with the request and isn't going to
honor that request. But you'd still like to keep users out of UI views
that aren't meant for them.

You could do a user access check at the start of each controller, or
perhaps within the resolve property of each route, but that would be
repetitive and it's something you could forget to do on occasion.

Sometimes projects take on a life of their own, and you end up with something unexpected.

I set out to create an template for CRUD-focused single page
AngularJS web applications, something I and perhaps my colleagues could
use as a foundation for writing new applications. But under the
momentum of self-applied scope creep, what I ended up creating was a
Grunt-powered codebase library management tool, with my original
template concept as the first codebase of potentially multiple
foundational codebases.

Last week I participated in a series of lightning talks at the AngularJS DC Meetup, hosted by Difference Engine,
and I thought I'd share the links to the slide decks and demos
presented (unfortunately, the equipment recording the entire event
failed, otherwise I would just share that).