HTML5 Zone is brought to you in partnership with:

My name is Sagar Ganatra and I'm from Bangalore, India. I'm currently employed with Adobe India and I work there as a ColdFusion Engineer. At Adobe, I have worked on various features of ColdFusion and ColdFusion Builder. I'm very much passionate of web technologies and have a very good understanding of jQuery, Flex, HTML5, Java and of course ColdFusion. Sagar H is a DZone MVB and is not an employee of DZone and has posted 42 posts at DZone. You can read more from them at their website. View Full User Profile

AngularJS: Resolving data services before instantiating the Controller and Template

07.01.2014
| 5458 views |
  • submit to reddit

I have been working on an Angular application for sometime now and I have started to like this approach to client-side development. It's a different approach when compared to developing applications using Backbone and Require. I was looking at routing in Angular and came across the 'resolve' property which can be used to resolve services before instantiating the Controller and it's corresponding template i.e. the domain models that are required for the View components are resolved first.

Look at a scenario where you are using a Search service to get a collection of objects that contain the search string. You can specify the route which will display the search results. When only the template and controller properties are specified, both are instantiated and the ng-view is updated with the specified template. The controller  would specify dependency on the SearchService,use this service to query the back-end and then update one of the $scope variables with the response data.

While the SearchService is fetching results, you would see that the template being displayed inside the ng-view container with template variables and the same getting updated when the service returns data. This is not ideal; the search results should be available before you load the controller; and the template should display data instead of showing template variables. The 'resolve' property in the $routeProvider mentions a set of promises that should be resolved before instantiating the controller and the template. Only when all the promises are resolved, the controller and the template are instantiated. Also the promise reference is injected into the controller as a dependency. Using this promise one can directly update the values in the template instead of sending a request to the Search service.

Here's the code for the routeProvider:

window.app = angular.module('routeResolve', [
    'ngRoute',
    'mockService'
]);

window.appMock = angular.module('mockService', ['ngMockE2E']);

window.app.config([
    '$routeProvider',
    function ($routeProvider) {
        $routeProvider
            .when('/search/:searchString', {
                templateUrl: 'partials/search.html',
                controller: 'searchController',
                resolve: {
                    searchResults: ['$route', 'searchService', function ($route, searchService) {
                        return searchService.getSearchResults($route.current.params);
                    }]
                }
            });

    }
]);

Here the route '/search/:searchString', specifies the 'resolve' object which includes a promise - 'searchResults'. It queries the searchService and returns a promise. When the service is resolved the Controller - 'searchController' and the template - 'partials/search.html' are instantiated. The Controller gets the promise object:

window.app.controller('searchController', [
    '$scope', 'searchResults',
    function ($scope, searchResults) {
        console.log('Inside Search Controller');
        $scope.userCollection = searchResults.data;
    }
]);

Notice that the promise - 'searchResults' is injected into the Controller and it contains the response data. This can then be used to render the template.



Published at DZone with permission of Sagar H Ganatra, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)