Monday, February 15, 2016

Pre-Loading AngularJS Controllers and View Templates

My goal is to asynchronously pre-load both view templates and controllers after the application is running and interacting with the user, but well before the router displays the views. In a "normal" load AngularJS eager-loads the controllers and lazy-loads the view templates. I also have a way to lazy-load the controllers, so both controllers and view templates will be loaded just-in-time.

So to achieve my goal first I am going to look at the normal eager-load/lazy-load scenario, and then build on that for a pure lazy-load scenario. That will become the foundation for achieving my goal of pre-loading both controllers and view templates before they are required, but after the application is running.

Normal Controller Loading

This really depends on what your definition of "normal" is, because I am going to use RequireJS to manage the individual scripts that make up the application. In a "traditional" AngularJS application I would load all of the scripts in the correct order in the HTML document. RequireJS helps manage the dependencies between the scripts, most importantly by allowing the dependencies to be define in each script. It also reduces the script tags to just one to bootstrap the application. If you want the details of using RequireJS with Angular I wrote another post about that: AngularJS + RequireJS.

Using RequireJS does not remove the possibility of deploying the application with a monolithic script, in fact it has a tool to combine the scripts. Often doing development with individual scripts is more manageable, but deploying with a monolithic script is cleaner. However a monolithic script can delay application startup, and in this case it would contrary to my stated goal.

My first example has two controllers and two templates and uses Angular-Route to manage them. The operations are logged to the console so that you can see the order in which they take place. I am just showing you enough here to build on as we go along. Angular is bootstrapped programmatically from main.js (not shown). The second controller and view look almost identical to the first. The project is available at the end of the article.

Sunday, February 14, 2016

JavaScript is Single Threaded

JavaScript is single-threaded, that is a well publicized fact. And we are reminded that we should write short operations to avoid problems. But why? More importantly, what is a simple "world-view" of how the JavaScript environment functions in a browser?

Frankly there are plenty of complex diagrams about all the gory details of what happens inside a browser for a page life-cycle. I, however, want a simple, functional view to explain in the JavaScript world the nuts and bolts you need to be an efficient programmer.

Thursday, February 11, 2016

AngularJS + RequireJS

The trick to working with an AngularJS application in RequireJS modules is to get a handle on two frameworks performing dependency injection at two different stages of the application.

So why bother? First of all, even though some of the AngularJS tutorials demonstrate putting your application module, controllers, and services all in one file that really is not the best way to organize your work. Follow the rule of coding one "type" per file and you will not have to put all of your work at risk every time you open up a file to make a change.

Second, once I have modularized my application into multiple source files the number of scripts that get loaded in the document escalates horribly. RequireJS allows each script to declare its own dependencies and with one script load in the document to bootstrap it they all take care of themselves. Plus, when I am looking at a module I know what the dependencies are, they are declared right at the top.

Tuesday, February 9, 2016

Building AngularJS Applications using Inheritance

It might be argued that you do not want to use inheritance for controllers or other AngularJS constructs because controllers are tightly bound to their views and therefore are unique. But I have a certification-style application that uses eleven different views for the start page, individual question types, and the results. All of these views have similar underlying functionality to work with the question being presented. Applying the DRY principle requires that I do not want to duplicate that functionality in every controller.

Even though the examples at are full of closures I would like to avoid them as much as possible. Building inheritance chains with prototypes is more efficient. Singleton services where the closures are only defined once may jump out as place where these closures are technically not less efficient, but sticking to a single pattern of object creation across the application is also very important. If you need some help on how prototypes work then visit this blog post: JavaScript Inheritance Best Practices. In fact nested scopes use prototypal inheritance, so I should use the built-in scope inheritance, right?

Sunday, July 12, 2015

JavaScript Inheritance Best Practices

Many sources document two major techniques and many minor variations to implement inheritance in JavaScript: constructors and prototypes. But constructors and prototypes are not exclusive, in fact they are inclusive and should always be used together. If you just use constructors or you just use prototypes, then you only did half of the job...

The best practices for JavaScript inheritance are:
  1. Move all of your methods out of the constructors and into the prototypes.
  2. Always define all of your properties in the prototype, it helps to document the new "type."
  3. Always use Object.create to link a new object to the "super-type" prototype, never build an instance of the "super-type" as the new prototype object. And always recreate the constructor property in the prototype.
  4. And always chain the constructor calls to the "super-type" constructor, even if they do not take any arguments and may not even do anything.
To explain them we are going to start from the beginning:

Saturday, June 27, 2015

Marrying Angular GUIs and Spring Web Services

Using Angular for your application GUI with Spring Web Services behind it combines the power of Spring and dependency injection with the single-page GUI framework of Angular. Using Angular with AJAX eliminates the page routing that a Spring MVC application forces on the application, but we can still use the Spring MVC application framework to provide a REST web service for that AJAX application.

The obstacle during development is the "same-origin" policy that restricts the Angular application to communicate with the same server it was loaded from. The solution is to put the projects side-by-side in the Spring Tool Suite (STS) and run them side-by-side in the Pivotal TC server.

Wednesday, May 27, 2015

Proxy: The Man in the Middle

Proxies occur naturally all over the place, for example in politics we elect someone to represent us in government because we cannot all be there. So it naturally follows that we would use the same pattern in software design. Here is an easy example: we have a class that implements an interface and submits a credit-card charge to a service provider. The interface provides what the client code expects, and the class adapts that to the provider. So this is actually an adapter pattern:

But what happens if the provider is offline? Well, we could change the adapter class so that it detects the problem and stores the transaction to process later. But that makes the class responsible for both interfacing to the service provider and caching transactions when the provider is not available. We would really like to stick as close as possible to Robert Martin's "Single Responsibility Principle" and separate responsibilities to easily manage them (Martin).