

Angular service or factory? - iffycan
http://iffycan.blogspot.com/2013/05/angular-service-or-factory.html

======
visarga
<rant> Too many different terms: provider, service, factory sharing more or
less the same functionality. They should use less common words with inside
meaning. It's confusing until you learn all of them.

And now, Polymer looks pretty similar to Angular, and I kind of like the focus
on components. The idea of packaging snippets of HTML, JS and CSS with
syntactic sugar is great. Why mix CSS from lots of things into one big file?
It's hard to follow the links after a while. Same with JS. Why put so much JS
in one place, instead of splitting it into components? Polymer does this
divide-and-conquer strategy better.

Not that you can't make components with Angular, but you can't dynamically
load them with controller and everything, or at lease you can't do that
easily. </rant>

~~~
michaelw
The benefit of the different types of providers comes in how and when they are
used.

Constants are especially interesting because they can be injected into the
.config function of a module. No other provider can be injected for the very
good reason that .config cannot inject transitive dependencies. Because
constants cannot have any dependencies (unlike services and factories) and do
not change (unlike values) they are safe to inject during the config phase.
FYI, the .run function is invoked (and its dependencies injected of course)
after all modules have finished loading and all config functions have been
run. If your provider needs another provider as part of its init then you can
set that up in the .run function.

Remember that DI in angular is not magic. It is quite literally the creation
of a closure whereby angular invokes your provider function with your
dependencies passed as arguments.

The difference between factories and services has a lot to do with how they
will get used and singularity of them.

I think the mistake of the documentation is that it leads the reader down the
path of the convenience functions first rather than instilling a deeper
understanding of the core DI mechanism.

As always with Angular docs, they are dense and it always pays off to
understand what you are reading as deeply as possible. Use the force, read the
source.

~~~
guac
> Constants are especially interesting because they can be injected into the
> .config function of a module. No other provider can be injected for the very
> good reason that .config cannot inject transitive dependencies.

It should be noted than you can inject _providers_ themselves in .config. Most
users do this with built-in $routeProvider (which provides $route).

It's not mentioned in the post but he could pass "awesomeProvider" into
module.config and (if it was more interesting than just a $get method) do
something with it during the config phase.

With $routeProvider you would use the .when method to configure angular
routing. It's .$get method returns the $route instance.

~~~
michaelw
$routeProvider and $location are special in that can be injected into .config.
It may be that they are actually implemented as special constants. I do not
believe that non constant providers can be injected.

Do you have a fiddle or plunk that shows this working?

~~~
guac
How about this: <http://jsfiddle.net/pJ8Mt/1/>

It's a poor example since I couldn't think of anything useful off the top of
my head but it shows how you might modify a service at config time by creating
its provider yourself.

Also I believe .config executes immediately so the provider needs to be
defined beforehand (in this case above .config, but probably better to define
it in another module to ensure it's available at config time). When I defined
it after .config angular complained it couldn't find awesomeProvider.

------
danso
Boy, this topic is one of the most confusing issues for anyone who is trying
Angular right now. The Yeoman build system, for example, creates factories by
default. The documentation for Angular, or at least when I was going through
it last month, hadn't seemed to catch up...so it was hard to know if factory
was a best practice or simply an issue of "you say tomatoe, I say tomato"

~~~
taude
I agree. Angular could really use some simplified and explicit documentation
for some of these concepts. The OPs article did a nice job of this.

------
artjumble
Great writeup. I just switched all my services to factories yesterday after a
talk with another developer.

One question though, is there any additional overhead to a service vs factory?

~~~
grinich
I think under the hood a service is created via a factory, so no.

