[00:09] The pattern involves returning an object from the function that will be your public API. In this case, I'll have a name property, initialize it to an empty string, and a speak-function. I'll create the function and then implement it to simply return, "Hi, I am," and then concatenate on the name of the droid.
[00:34] To create an instance of an object using our factory we can create local variable droid, and then invoke our droid factory. The key line here is these parentheses are actually invoking the function. When we invoke it, the return statement will happen and an object will be returned out.
[00:52] We can then work with the object. We can say, "Droid.name = C3PO," for example, and we can log out the droids speaking. If I save that, I get, "Hi, I am C3PO."
[01:10] There is a popular variation to the module pattern called the revealing module pattern. What happens with the revealing module pattern is things start explicitly private, and then choices are made about whether they become public.
[01:24] For example, if I take our speak implementation and I turn it into a speaking privately function here, then I can choose consciously to expose it via the public API.
[01:38] So of we logged out the droids speaking privately method right now, this method is private because it's enclosed in the closure from here to here, and not returned on this object.
[01:52] If we save that we should get an error because this is a private function. However, you notice that if we remove that line the calling speaks still works because we are exposing our private method here. The revealing module pattern is a slight variation on the module pattern.
[02:13] Let's look at how we could plug this into an AngularJS application. I'll switch over here to my Angular app. We'll copy our revealing module and bring it across to our AppJS in our Angular code. I'll paste it here.
[02:27] What we need to do is register our factory with Angular. We call it the factory method off of the Angular module. We give it a name, we call it droid in this case, and then we give it a reference to our Angular function.
[02:41] If we then ask for an instance of our droid service to be injected, Angular will know because we registered it with the factory function, that this is a factory and it needs to invoke the function which will return back an object.
[02:58] Once Angular has that object, it will hand us an instance of it in our controller. We can then work with the object, set its name as we did, before to C3PO. We can then assign our droid controllers message property which outputs the page to our droid speak-function.
[03:18] If we save that, we'll see, "Hi, I am C3PO," inside of our Angular application.
[03:24] To recap, if you want to use the module pattern or a variation of it such as the revealing module pattern, you'll need to invoke as we did here your factory, which will return you an object.
[03:37] To tell Angular that your object is a module and it needs to be invoked, you register it with the dot factory function off the module. Angular will then know to invoke your function, in other words call it with the parentheses, and send you in an instance of your object.
Was hoping to learn if there are any particular scenarios to choose Service over Factory or vice versa.
I still have a few more video to record and add to the playlist that go over the tradeoffs but for the most part it's more of a coding style thing than any actual performance or practical difference. For example, Service services lend themselves to using ES6/ES2015 classes or an object oriented style while Factories let you use a module or revealing module style of coding. That said if you want inheritance you would lean towards the service recipe.
Thanks! Looking forward to seeng new episodes.
If we were to add another controller and inject the droid factory, angular would reuse the same instance and would not create a new one?
Yes, you are correct it would be a singleton.