This lesson describes what is really happening when you use the angular
factory and how you can make your factories even more dynamic in creation.
This gets further into the internals of AngularJS by showing you how a factory is built dynamically for you and how they have reduced the plumbing you need to make applications.

Providers

Factories are a common used paradigm in AngularJS. They allow you to configure a function that returns an object which you can then -- we will give it a title of "StarCraft" -- inject into controllers. You say this game matches up with this game up here. Once we have that we can replace "Awesome" with "game.title" and it automatically syncs to whatever is returned from our object.

**John Lindquist**: That's great but what actually is a factory? You will hear some people refer to it as a provider. What does that actually mean? That means that if you were to see what factories really are you would look at the "provide object". Which basically is the go to guy, meaning that sets up everything for the injector.

Anything that can be injected into a controller or what-not is configured through this provider. If you are to say "provide" and then grab this ".factory". If I refresh it works just as if it did before because that "app.factory" is just simply short-hand for using this "provide object" and then defining a factory on it which sets up the providers for your app.

"Factory" is really just shorthand for the provider which sets up a more generic provider which returns things or objects that have "get" functions. This is an internal function. It is going to be called by the injector when it is created inside of AngularJS. A "get" is going to return an object which is going to have a title of "StarCraft".

This is going to work the exact same way as it did before. Basically if you look at the before and after of this before we had a factory that returned an object with a title of "StarCraft" and after we have a provider that returns an object with a "get" function that returns that same object. Basically factory is an easier way of doing this.

You do not have to define this "get" function because factory sets it up already for you. If you wanted to find a provider, this will give you a bit more flexibility down the road. If you want to do something like select all of this and then define the provider on our app and then get rid of the provider here.

This should all still work because again this is just a short-hand way of doing what we did before but what this allows us to do is actually inject the game provider and allow us to configure it a little bit. You have probably seen this in things like route provider and location provider when you are configuring html5 mode or routes or what-not.

If you want to set up something like game provider and set the type of game. Now you want to set it to "WarCraft" instead of "StarCraft". You could just simply define a type here, expose a method, and set type with a value. Then we could say type is value and title is actually going to be "type + "Craft"".

If you refresh now we will get "WarCraft" because what we've done is we have exposed an api or configurable method that allows us to configure what this is going to be when it ends up as the actual instance. You are configuring the factory and what it is going to return. We could come in here and change it to "puzzle" for instance and get "PuzzleCraft." That is what a factory is if you break it down into its pieces. It is a provider which is actually configured through that dollar provide. This is a convenience method on your app to configure your providers.

If you want to configure the factory, which is going to return the instance it is going to use, then you would use this. Inject the game provider that is configured here into your config function and then call whatever methods you set up to configure it.

Hopefully that makes sense. We will go into more details on other providers, services and what-not in future videos.

Providers

Share this video with your friends