CODEWITHSUNDEEP
javascriptangularjsnode.jsbrowserify
Golo Roden
Golo Roden

Reputation: 150654

Angular services and browserify

I am using AngularJS for a SPA, and I am using browserify to build my application. Now the question came up whether we should write Angular services in the classical way, or simply require them.

As Angular services are singletons, this could be easily done with require as well: Simply expose an object literal, and you're done. Factories are also possible, simply expose a function. And so on ...

The only disadvantage I can currently think of is that I am not able to access other real Angular services from such a file (like, e.g., $http), but with browserify in the background this does not seem to be that important. E.g., you could easily use Node.js's http module for that, thanks to browserify.

So what do you think of this? What are other advantages and disadvantages for this?

PS: Please note that I'm not asking for whether this is good or bad, as this is probably mainly subjective. I'm rather interested which opportunities appear, or which risks I have to deal with.

Upvotes: 1

Views: 193

Answers (3)

graffic
graffic

Reputation: 1412

If you require things like $http you won't have any way to inject dummy/mocks of those services during testing.

Although somewhere you will do the wiring between your super-duper service that needs $http and the place you need it.

The first thing that came into my mind is resolvers in routes. You can even have some helper methods to deal with declaring the same dependencies many times.

Imagine this module:

function SuperResource($http, pathExpression) {}

exports.SuperResource = SuperResource;
exports.superResourceFactory = function(pathExpression) {
    return [
        '$http',
        function() {
            return new SuperResource($http, pathExpression);
        }];
};

Somewhere you will do:

var myModule = require('./myModule.js');

resolvers: {
     usersResource: myModule.superResourceFactory('/users')
}

Or even you could have a user modules that defines the user resource:

var myModule = require('./myModule');

exports.userFactory = ['$http', function() {
    return new myModule.SuperResource($http, pathExpression);
}

Yes, these are angular specific helpers in an otherwise angular free code, but at least they're isolated in their own method/name.

Upvotes: 0

airtonix
airtonix

Reputation: 5164

It's bad.

Just use browserify to initially load in all the modules you need.

  • you miss out on $httpBackend
  • your code becomes harder to follow, ie, there is very rarely a point to reuse that directives controller
  • you miss out on $http interceptors
  • you miss it in being able to modify and interact with other injectables.

The only thing I'd use browserify/webpack/requirejs for in an angular app is two things:

  • creating js bundle
  • injecting templates as strings into the angular template cache as a module.

Personally this kind of approach is just a pointless complication.

Upvotes: 0

sma
sma

Reputation: 9597

One disadvantage to doing this is writing unit tests. It will be difficult to mock your dependencies if you are simply requiring them rather than using Angular's dependency injection.

This is somewhat of a dealbreaker for me because one of the many benefits of using Angular is the testability of the framework.

Upvotes: 3

Related Questions