Best practice for handling non-trivial AngularJS application initialization requirement?

Question

I have an application which has some specific (non-trivial) initialization requirements, and it's not really clear what the best practice solution to this is. Sorry for the wall of text. The question itself is not that complex, but I need to make sure my reasoning is clear.

First, the application itself:

• It has user authentication, though it is only forced at two points in time:
  1. The first time the application is loaded (the very first time). I'll just call this requirement (1) through the rest of the question.
  2. On a need-to basis when interacting with server-side. This part I have already solved with something similar to http://ngmodules.org/modules/http-auth-interceptor, though a custom solution (which is required because the application needs to use some services that I don't want to be Angular dependent). I'll call this requirement (2) through the rest of the question.
• There are two controllers relevant to this question:
  • A navigation bar controller (fixed, not bound to the view).
  • The controller applied to the view used (ng-view).
• It is started manually using angular.bootstrap.

This question is about the user authentication handling. Requirement (2), where a user has to authenticate on a need-to basis, is already solved. It is currently handled like the following:

1. Some server-side request is performed by one of my Angular service modules. The request can potentially result in a 401 response if the applied authentication token has expired (or doesn't exist all-together).
2. The application service module which made the request discovers the 401 response and applies a $rootScope.$broadcast('app:auth').
3. The authentication broadcast is picked up by some code using $scope.$on('app:auth'), shows a modal authentication dialog, and then makes sure the original service request promise is resolved / rejected (rejected if the user presses cancel in dialog).

The only differences between requirement (1) and (2) is that (1) should be a forced authentication dialog (the user cannot simply reject it with 'cancel' or 'esc'-button) and that (1) should happen as early in application initialization as possible.

Now, my issue is with requirement (1), really, and Angular best practices. There are a couple of ways to do this that I can see:

1. Perform this one-time authentication outside of Angular completely. The downside here is obviously that I have to write essentially duplicate logic for both the modal dialog box and the initialization. Some of this can be shared, but not all.

2. Perform this one-time authentication in some special (fixed) controller of the application (like the navigation bar controller).

3. Perform this one-time authentication in angular.module.run.

The aim here is obviously to "force" an authentication on the user before he (or the application) can trigger something else in the application.

I would love to use number (3), since I would then be able to re-use all code already in use by requirement (1). However, you then instead run into the question of where to place the event-listening code. No controllers / parts of the application are yet started at this point (only the injections are complete).

If I place the logic for authentication events in an application controller, that controller won't even have started at that point, and thus won't have been able to register with the event. If I place the $rootScope.$broadcast inside a $timeout with 0 delay, my navigation bar controller have started, but not my view-bound controller. If I place the $rootScope.$broadcast inside a $timeout with 100 ms delay, both my controllers have started (on MY computer).

The issue obviously being that the amount of delay I need to use is dependent on the computer and exactly what scope the event handler code is placed in. It's also probably dependent on exactly in which order Angular initialize the controllers found through-out the DOM.

An alternative version of (3) might also be to do the $rootScope.$broadcast in angular.module.run, and have the event-listener attached to the $rootScope itself. I'm leaning towards this being the most straith-forward way to do it.

See the following plunker (which tries to higlight the timing issue only): http://plnkr.co/edit/S9q6IwnT4AhwTG7UauZk

All of this boils down to the following best-practice question, really:

Where should application-wide code and non-trivial application initialization code really be placed? Should I consider the $rootScope as the actual "application"?

Thanks!

Answer 1

You should put application-wide non-trivial initialization code in providers. Providers offer the most flexibility with regards to initialization, because they can be used to configure the service before the instance of the service is actually created by the $injector.

app.provider('service', function() {

    // add method to configure your service
   this.configureService = function() { ... };

   this.$get = function (/*injectibles*/) {
        // return the service instance
        return {...}; 
   };

});

The config block is your opportunity to initialize your providers. Inject your provider into your config function (notice the required 'Provider' suffix) and perform any initialization code that you need to setup your provider. Remember, that the provider is not the service - it is the thing that the $injector will use to create your service.

app.config(function(serviceProvider) { 

    serviceProvider.configureService();
    serviceProvider.setTimeout(1000);
    serviceProvider.setVersion('1.0);
    serviceProvider.setExternalWebService('api/test');

    ... more configuration ...
};

There are several reasons why providers and config blocks are suitable for initialization:

1. config blocks are called only once and very early in the application life cycle
2. providers are configurable - meaning you can initialize the provider before actually creating the service.
3. The main purpose of the config block is initialization. It supports injection of providers as an opportunity to perform the initialization.
4. Providers are singletons (like factories and services) - meaning that one service instance is created by the $injector and then shared between all controllers, directives, etc - basically any where that the service is injected.

Now for requirements (1) and (2) - I think you're on the right track. I suggest creating an authLogin directive that shows or hides a modal login dialog based on an "IsAuthenticated" property that is being watched on the scope. This would take care of the requirement to show the login modal dialog when the application starts up. Once the user authenticates successfully, set the IsAuthenticated property to true (which would then hide the dialog).

The second requirement is handled through an HTTP interceptor. When a request is made and the user is not authenticated, the service would broadcast the event starting from the $rootScope downwards towards the child scopes. You can have the same authLogin directive listen for the event and handle it by setting the IsAuthenticated property to false. Since IsAuthenticated is a watched property, it would trigger the modal login dialog so the user can log in again.

There are many ways you could implement requirements (1) and (2). I offered a slight variation on your approach, but in general it is the same approach.

Answer 2

The short answer :

Application wide code should be in a service.

Application initialization code should be in the run block.

Longer answer :

Application wide code like your Authentication should be defined in a service. This service should expose API's which the rest of your application can interact with in order to achieve that task. Ofcourse the job of the service is to hide the implementation details. The service itself should take care of where it fetches the authentication information from ( initially ) - perhaps from cookies, perhaps from your local storage or session storage.. Or perhaps it even does a http call. But all this gets encapsulated into that Authentication Service.

Because now you have written a separate service and you can inject stuff into your run block you are good to go. You dont really need the $rootScope. The $rootScope is another injected service. But because it participates in the dirty checking mechanism and seemingly this service need not.. you dont need to over burden $rootScope with this additional task. Its not its job and perhaps it can be delegated to some other service whose only task is authentication. Because your service is also a singleton it is amazing at maintaining states as well. You could perhaps set a flag , something like isAuthenticated which can be checked later if need be.

Oh, between your modal should also be a service.. See the $dialog service in Angular UI if you havent already. Which means that authentication can directly work with the $dialog service.