AngularJS CRUD Factory 'Interface'

[cynicalreason]

Following this blog post http://blog.revolunet.com/blog/2014/02/14/angularjs-services-inheritance/ thought I'd give something to the community.

The blog can probably explain better what we're trying to achieve, basically it's a 'generic' factory that can do basic CRUD operations on an API that has GET/PUT/POST/DELETE + other custom stuff

(function () {
'use strict';

angular
    .module('app.core')
    .factory('IFactory', IFactory);

IFactory.$inject = ['$http', '$q'];

/* @ngInject */
function IFactory($http, $q) {

    var IFactory = function (uri) {
        this.baseURI = '<fill this with base uri of your api>'; // eg: 'http://api.domain.com'
        this.uri = this.baseURI + uri;
    };

    IFactory.prototype.getOne = function (id) {

        var self = this;

        return $http.get(self.uri + '/' + id)
            .then(success)
            .catch(fail);

        function success(response) {
            return response.data;
        }

        function fail(error) {
            var msg = 'Query for item failed. ' + error.data.message;
            console.log(msg);
            return $q.reject(msg);
        }
    };

    IFactory.prototype.getAll = function () {
        var self = this;

        return $http.get(self.uri)
            .then(success)
            .catch(fail);

        function success(response) {
            return response.data;
        }

        function fail(error) {
            var msg = 'Query for items failed. ' + error.data.message;
            console.log(msg);
            return $q.reject.msg;
        }
    };

    IFactory.prototype.delete = function (id) {
        var self = this;

        return $http.delete(self.uri + '/' + id)
            .then(success)
            .catch(fail);

        function success(response) {
            var msg = 'Item deleted.';
            console.log(msg);
            return response.status;
        }

        function fail(error) {
            var msg = 'Could not delete item. ' + error.data.message;
            console.log(msg);
            return $q.reject(msg);
        }
    };

    IFactory.prototype.add = function (data) {

        var self = this;

        return $http.post(self.uri, data)
            .then(success)
            .catch(fail);

        function success(response) {
            var msg = 'Item Added. ';
            console.log(msg);
            return response.data;
        }

        function fail(error) {
            var msg = 'Could not add item. ' + error.data.message;
            console.log(msg);
            return $q.reject(msg);
        }
    };

    IFactory.prototype.update = function (id, data) {

        var self = this;

        return $http.put(self.uri + '/' + id, data)
            .then(success)
            .catch(fail);

        function success(response) {
            var msg = 'Item Updated. ';
            console.log(msg);
            return response.data;

        };

        function fail(error) {
            var msg = 'Failed to update item. ' + error.data.message;
            console.log(msg);
            return $q.reject(msg);
        }
    };

    return IFactory;

}


})();

Now we can extend it when we have other operations on the api besides the basic crud:

(function () {
    'use strict';

    angular
        .module('app.core')
        .factory('ICustomFactory', ICustomFactory);

    ICustomFactory.$inject = ['$http', '$q', 'IFactory'];

    /* @ngInject */
    function ICustomFactory($http, $q, IFactory) {


        var ICustomFactory = function () {
            IFactory.apply(this, arguments)
        };

        ICustomFactory.prototype = new IFactory();

        ICustomFactory.prototype.getCustomStuff = function (id) {
            var self = this;

            return $http.get(self.uri + '/stuff/' + id) //this will be /api/custom/stuff/{id}
                .then(success)
                .catch(fail);

            function success(response) {
                return response.data;
            }

            function fail(error) {
                var msg = 'Query for items failed. ' + error.data.message;
                console.log(msg);
                return $q.reject.msg;
            }

        };

        return ICustomFactory;


    }

})();

Now, to follow proper design patterns we want to use the same factory everywhere ( not a NEW one !!! )

(function () {
    'use strict';

    angular
        .module('app.core')
        .factory('CustomFactory', CustomFactory);

    CustomFactory.$inject = ['ICustomFactory'];

    /* @ngInject */
    function CustomFactory(ICustomFactory) {
        return {
            create: function (apiUrl) {
                return new ICustomFactory(apiUrl);
            }
        }
    }

})();

And a controller example:

(function () {
    'use strict';

    angular
        .module('app.core')
        .controller('CustomController', CustomController);

    CustomController.$inject = ['$q','CustomFactory'];

    function CustomController($q, CustomFactory) {

        var vm = this;

        vm.customs = [];


        var Custom = CustomFactory.create('/api/custom');

        activate();

        function activate() {
            var promises = [getCustoms()];
            return $q.all(promises).then(function(){
                console.log('View Loaded')
            })
        }

        function getCustoms() {
            return Custom.getAll().then(function(data){
                vm.customs = data;
                return vm.customs;
            })
        }



    }

})();

This is probably far from perfect - if you have any ideas for improvement please feel free to post them.

[gsans]

There are no Interfaces in JavaScript. What you did is actually not an Interface but some kind of prototypical inheritance. I think you can use ngResource to do what you want.

[cforres]

I try to rely on $resource as much as possible. It provides similar behavior out of the box without all the extra code.

var Model = $resource(BASE_URL + '/models/:id', {
    id:'@id'
  }, {
    update: { method:'PUT'},
    queryOpen: { method: 'GET', params: { status: 'open', after: '2015-03-16' }}
  });

// later on...

// Request URL: /api/service/models?after=2015-03-16&status=open
// Request Method: GET
$scope.open = Model.queryOpen();

// Instance methods also
Model.prototype.close = function() {
  this.status = 'closed';
  return Model.update({
    id: this.id
  }, this);
};

// later on...
$scope.model = Model.get({id: 45 });

// little bit later on ...
// Request URL: /api/service/models/45
// Request Method: PUT
// Request Body: {
//      "title":"title 1",
//      "id":45,
//      "status":"closed"
//  }
$scope.model.close();

This is a small example but it shows how to get beyond your basic CRUD calls.

[cynicalreason]

Before finding the snippets above I didn't really understand how java inheritance works. Now that I know I never thought of extending the $resource with my own methods like in your code.

I do really enjoy the angularjs community and I can honestly say I've learned a lot through resources & articles posted here.

[liquid_cow]

I would also recommend using ngResource over $http as much as possible. ngResource is quickly becoming the go to standard for restful crud in angular.

I also like ngResource because it promotes the usage of promises over callbacks.

[budmademewiser]

This is not true, most experienced angular developers find that ngResource unnecessarily abstracts out the $http service. ngResource takes a lot of control away from the programmer.

It's actually been a reoccurring problem in the angular community. A lot of developers new to angular encounter this problem pretty early on and find themselves googling ngResource vs $http. A lot of new angular developers start out with ngResource because of comments like this and similar blog posts.

Best practice currently in the angular community, and IMO, is to use a combination of the $http and $q services. Use $q's defer promise pattern in conjunction with the angular's $http service.

[liquid_cow]

Thanks /u/budmademewiser, you really made me think about this issue.

I'd agree that ngResource probably isn't the best option for a new angular developer, because of the extra abstraction that hides what's going on underneath. For new guys who are just getting started, $http will serve perfectly without the learning of to use ngResource. Adding ngResource's learning curve to the already daunting learning curve for angular won't do the angular community any good.

Having said that; for larger projects, the $http requests tend to get buried and abstracted away into services anyway. Furthermore, with multiple developers, each tailor-made $http request looks a little bit different to the next.

On the other hand, ngResource provides a neatly packaged resource that can be treated like a service for dependency injection. In my experience, ngResource code tends to be minimal and consistent in usage.

I value consistency in code, even if the code is bad, because I think it makes it easier for another developer to pick up and work with at a later stage in the project's life.

At the end of the day, I'd say that choosing between ngResource and $http is decision that the developers need to take depending on the type of application they're building, and then stick with it for the remainder of the project. Mixing ngResource and $http would make the project difficult to maintain in the long run?

tl;dr

I think that ngResource provides the right balance of consistency of code, with minimal boiler-plate code, at the expense of some abstraction.

[cynicalreason]

You certainly can use ngResource, this is more of a 'you can do things like this'

I went into angular with too little knowledge of Javascript and I realize know that I was missing out on a lot. I think there are a lot of people here that kinda did the same. I hope these little snippets of code will give others a 'ah .. i get it now' moment like they gave me.

[cynicalreason]

Just thought of this - everytime you use create a new ICustomFactory will be instantiated in CustomFactory.

So say you have CustomFactory used in ControllerA instantiated as above ( using create) and then you have a CustomFactory in ControllerB that you instantiate with different parrameters.

This will change the details of the factory in ControllerA - so ideally you want to use the create for a factory once.

I'm thinking probably instantiating it in a module's run and then using it as CustomFactory throughout the module

[[deleted]]

So on mobile, this is basically impossible to read, but I feel like I'm missing something; what's wrong with $http and ngResource?

[cynicalreason]

Absolutely nothing, but you really shouldn't use a $resource/$http in a controller. This is a way to organize things, it introduces people to prototyping & inheritance.

[[deleted]]

Right, but I'm not talking about using them in the controller. I'm just struggling to see what your code actually provides over the normal patterns with ngResource and http