4 ms·

I enjoy quite a few parts of Angular, but its choice of naming between Factories & Services is maddening. The fact that Factories are not Factories-as-seen-in-a

• spion 12y ago
  Nope, they're all singletons. While providers may be useful, the distinction between service and factory is completely useless (service is completely unnecessary :) At this point the angular team should probably just deprecate module.service and remove it from the docs to avoid causing this massive confusion.
  • jonny_eh 12y ago
    Why not the other way around? You can use .service as you would a .factory, and it makes sense that .service is used to create services just like .controller creates controllers.
    • spion 12y ago
      Because .factory is slightly more general (can return non-objects), and it can't be called .service because backward compatibility.
      • jonny_eh 12y ago
        The article seems to be down for me. Can you give an example of a case where a .service won't cut it but a . Factory would?
        • minznerjosh 12y ago
          .factory('$timeout', function($window) { var $timeout = $window.setTimeout; return $timeout; }) .service('$timeout', function($window) { // $timeout is a function, not an normal object. Why would I use a constructor //function to provide it? });
          • alttab 12y ago
            I want the bike shed to be blue, god dammit!
• jacques_chester 12y ago
  Bonus points round: Scopes are the actual Controllers, after instantiation. Controllers are actually Factories that annotate Scopes until you have the instance. $controller() is ... I don't even know any more.
  • minznerjosh 12y ago
    I don't know if I'd say Scopes are controllers after the controllers are instantiated. Scopes are more of a view-model which are, yes, annotated by Controllers. However, if you put your Controllers on the Scope (via $scope.MyCtrl = this; in the constructor, or via the controllerAs syntax), your controllers are your controllers, placed on the view-model (the scope.) But this is really just semantics at this point. I totally get what you're saying.
• badman_ting 12y ago
  I can see why we need providers, and either services or factories, but not both. I prefer not to use 'this' in JS where possible, so factory it is.
• minznerjosh 12y ago
  Really, Services and Factories are just a shorthand way of creating providers. .factory('foo', function() { var foo = {}; return foo; }); is the same as: .provider('foo', function() { this.$get = function() { var foo = {}; return foo; }; }); And, .service('foo', function() { this.bar = 'bar'; }); is the same as: .factory('foo', function() { function Foo() { this.bar = 'bar'; } return new Foo(); }); is the same as: .provider('foo', function() { this.$get = function() { function Foo() { this.bar = 'bar'; } return new Foo(); } });
  • acoyfellow 12y ago
    So when should we use each?
    • minznerjosh 12y ago
      That can be a matter of personal preference, so the best I can do is share my preference. I usually use the "service" method because most of my services are objects, and I have no aversion to constructor functions. However, if I want my service to be a function (a la $http or $timeout,) I'll use a factory (because I don't want a constructor to be new-ed, I just want to create a function.) And, as the article states, I'd use a provider if I want to provide methods to configure my service before it is instantiated. I think a lot of it comes down to semantics. Maybe it's just me, but describing my object via a constructor function (as a "service") makes it feel a bit weightier than creating and returning a POJO in a factory. But, from a practical standpoint, you can see it as this: A provider is responsible for creating (providing) an injectable (as a singleton) object that others can request to be injected. The provider creates this object in its $get method. It can also have methods/properties other than $get that can be called/modified in the config stage to configure the object it will create. But, often times (maybe the majority of times,) you don't need to configure your injectable before it is created, so we really only care about the $get method of the provider. This is where the "factory" API comes in. It just eliminates all the boilerplate around creating a provider that only has a $get method. And finally, for reasons that are not entirely clear to me, the angular team also decided to provide a shorthand for creating a constructor, and returning a new instance of that constructor in the $get method of the provider (or the factory function if you like.) And that's what the "service" API is. So, the provider is the root API, factory is sugar on top of the provider API, and service is sugar on top of factory API.