I have been working on AngularJS for a while and have researched quite a lot. I am working on building reusable custom components/widgets using AngularJS directives. I have been quite successful at it. However, I want to adhere to inheritance while doing the same.
Let me explain with an example.
I have created a directive myButton that creates a button with all the styles & functionality. Now I would like to extend/inherit this myButton to create a myToggleButton with some added features & functionality. I do not wish to rewrite myButton features again.
I have explored various options.
As suggested in https://gist.github.com/BrainCrumbz/5832057, I created a factory/service and injected it into the directive. But this is not allowing me to take full benefit of the inheritance. I am still having to rewrite most of the properties.
I tried using plain object-oriented JavaScript for inheritance but in that case I would not be using AngulrJS directives. I want to follow Angular concepts strictly.
So any suggestions would be most welcome.
I have also found most inheritance examples less than ideal but I have come up with a solution I think is clean and allows for fully inheritance.
As services and directives do not have prototype information available in them and extending Object directly is not good you will want to create a high level base class which could contain constants or very simple generic logic.
var BaseService = function() {};
BaseService.prototype.toast = "french";
BaseService.prototype.halloween = "scary";
Next lets create an abstract service (same logic for a directive) that can be extended.
module.factory('AbstractDirective', function(
$http, $q, $rootScope, $compile, $timeout) {
$.extend(this, new BaseService);
// Additional logic and methods should be appended onto 'this'
this.doStuff = function() {
alert("abstract function called");
};
this.halloween = 'fun';
// If adding a variable to the prototype of this extended class is desired
// then this function would need to be extracted to its own variable
// where the prototype values can be set before the function
// is passed to the factory.
return this;
}
Now lets create an actual implementation:
module.directive('DirectiveImpl', ['AbstractDirective', function(AbstractDirective) {
$.extend(this, AbstractDirective);
// A great part about this implementation pattern is that
// DirectiveImpl does not need to pass anything to construct AbstractDirective.
// Meaning changes to AbstractDirective will have less impacts
// on implementing classes.
this.doStuff = function () {
// Call
AbstractDirective.doStuff();
// Implement some logic additional
alert(this.toast + "Toast\nHalloween is " + this.halloween );
}
return this;
}]);
for services use
module.factory
instead of
module.directive
When the doStuff function is call for DirectiveImpl you will get 2 alerts:
abstract function called
then
French Toast
Halloween is fun
A similar pattern can be followed to allow full inheritance for controllers as well but there is a bit more to get that to work.
I used this implementation (based on Enzey's model) to get my directive to work as intended.
module.directive('DirectiveImpl', ['AbstractDirective', function(AbstractDirective) {
return {
controller: ['$scope','$element', function( $scope, $element ) {
$.extend($scope, AbstractDirective);
// A great part about this implementation pattern is that
// DirectiveImpl does not need to pass anything to construct
// AbstractDirective.
// Meaning changes to AbstractDirective will have less impacts
// on implementing classes.
$scope.doStuff = function () {
// Call
AbstractDirective.doStuff();
// Implement some logic additional
alert($scope.toast + "Toast\nHalloween is " + $scope.halloween );
}
},
link: function( scope, element, opts ) {
scope.doStuff();
}
}
}]);
Related
I have a page that consists of several panels that are very similar in their structure. They use one controller each. But due to their similarity i reuse the controller function like so:
function panelController($scope) {
...
}
angular.module('myApp.controllers')
.controller('panel1Controller', panelController);
angular.module('myApp.controllers')
.controller('panel2Controller', panelController);
The result is that panel1 and panel2 have their own distinct scopes but will look the same in terms of what the view can bind to.
Now however I am at a point where I want to use the same pattern for panel3 but with a slight extension. That is, I have something I want to include only in the $scope for panel3 only. So ideally I would like to be able to do something like this:
function panel3ControllerExtension($scope) {
$scope.panel3Field = "I must only live in panel3";
}
angular.module('myApp.controllers')
.controller('panel3Controller', panelController, panel3ControllerExtension);
But that's not possible. Are there any good patterns for this out there?
Edit:
The similar panels are similar only in what they expect the $scope to contain. Specifically the expect the scope to contain a customer object. So e.g. panel1 binds to $scope.customer.name and panel2 to $scope.customer.phone. ...So since they look different and behave different I don't think making a directive of them are the way to go. Correct me if I'm wrong.
Controllers in Angular are used effectively as constructors. So the rules for "inheritance" in Javascript apply to them. Some methods for extension:
apply/call the "base" function:
function panel3Controller($scope) {
// add the functionality of `panelController` to this scope
// in OO terms this can be thought of as calling the `super` constructor
panelController.call(this, $scope);
// add panel3 specific functionality
$scope.panel3SpecificThing = "...";
}
// just register the new controller
angular.module('myApp.controllers')
.controller('panel3Controller', panel3Controller);
This method will probably get you what you want with the minimum modifications to your code.
Use JS inheritance: Make the controller a JS "class" and let the child controller prototypically inherit from it. You may also want to use this in conjuction with the controller as syntax:
function PanelController($scope) {
this.$scope = $scope;
this.something = '...';
}
PanelController.prototype.someMethod = function() {
...
}
function Panel3Controller($scope) {
PanelController.call(this, $scope);
this.somethingElse = '...';
}
Panel3Controller.prototype = new PanelController();
Panel3Controller.prototype.constructor = Panel3Controller;
Panel3Controller.prototype.panel3SpecificMehod = function() {
...
};
If you are using ES2015, the above can be simplified:
class PanelController {
constructor($scope) {
...
}
...
}
class Panel3Controller extends PanelController {
constructor($scope) {
super($scope);
...
}
...
}
Again, you just register the new controller alone:
angular.module('myApp.controllers')
.controller('panel3Controller', Panel3Controller);
If the properties and methods are placed in the controller, as shown here, use the controller as syntax, i.e. in the HTML:
<div ng-controller="panel3Controller as p3ctrl">
<span>{{ p3ctrl.somethingElse }}</span>
Having a module system in place makes this pattern really useful.
Depending on the exact functionality of the controllers and, as pointed out in a comment, you may be able to extract the functionality of the controller(s) in one or more services. Then the controllers will be thin wrappers for these services. Again whether this is a good idea or not depends on the exact functionality of the controller(s).
As for directives: they are always the way to go :) And you can reuse your code as the controller of the directive instead of using it with ng-controller. You can even use two directives with different templates (the customer.name and customer.phone binding for example) and the same controller.
tl:dr;
I want to consider the 'controller as' approach to simplify my inheritance process however I see some pitfalls around dependency injection and use in directives.
preface
I've been working on a pretty big Angular application for the last 6 months. I come from a more OOP language background but feel I've adapted fairly well to some of the quirkiness of javaScript and Angular.
With an application of this complexity, I think it necessitates great architectural solutions. I've elected to have baseController classes that UI controllers can inherit from using the current approach below.
current approach
All the current UI views/components/etc. are utilizing the $scope as the view model approach, aka. the classic approach. I achieved the controller inheritance like so:
NxBaseUiController
var NxBaseUiController = function($scope)
{
$scope.isLoggedIn = function(){}
$scope.doSomethingElse = function(){}
}
Here's a subclass base controller and it's inheritance
NxBaseListUiController
var NxBaseListUiController = function($scope)
{
var NxBaseUiController = require( './NxBaseUiController' )
NxBaseUiController.apply( this, arguments )
NxBaseListUiController .prototype = Object.create( NxBaseUiController.prototype );
$scope.query = require( './QueryModel' ).new()
}
What's crazy about this approach is that I'm having to maintain 2 series of inheritance all while keeping in mind of the existing NG scope inheritance that takes place in the view hierarchy. You can see this in the following UML diagram:
src - http://i.imgur.com/LNBhiVA.png
This all works so far, but moving onto a new section of the app, I want to start looking at the 'Controller As' syntax to see if there can be any simplification of the above approach.
questions
In all the examples I've seen of the 'controller as' approach, any methods attached are not defined on the prototype but rather the actual constructor like so:
function SomeController($scope)
{
this.foo = function(){};
}
Is there a reason why you wouldn't want to define the controller methods on the prototype?
The only reason I see attaching to the prototype as being problematic is you lose reference to your injected dependencies.
I realize I am coming at this from a very OO approach, however w/ an application of this size, being able to draw upon development patterns like inheritance seems necessary to solve code duplication.
Am I approaching this completely backwards? Are there any proven methods to achieving some semblance of inheritance in the controllers that doesn't require some wonky hack to work w/ the $scope?
There is no reason you can't use the prototype so long as you are OK with losing the ability to have actual private data vs having conventionally private data.
Let me explain with code:
function MyClass($http){
var privateData = 123,
$this = this;
$this.getAnswer = function(){
return privateData;
};
}
MyClass.$inject = ['$http'];
In that example you can't actually change privateData once the class has been instantiated.
function MyClass($http){
this._privateData = 123;
this.$http = $http;
}
MyClass.$inject = ['$http'];
MyClass.prototype = {
getAnswer: function(){
return this._privateData;
},
callHome: function(){
var _this = this;
_this.$http.get('/api/stuff')
.success(function(data){
_this.stuff = data;
});
}
};
In that example I am simply using a convention of prefixing my properties with an underscore (_) to signal that they should be treated as private.
Unless you are building a re-usable library however, this might not be a big deal.
Mind you some of this get's much simpler with ES6, so I would look into something like 6to5 or TypeScript if I were you. It might gel a little better with your OO background to write code like this:
//100% valid ES6
class MyClass extends BaseClass {
constructor(something){
super(something, 'foo');
}
someMethod(){
return this.foo;
}
}
I heard it's a good practice to use the controllerAs syntax along with bindToController: true in directives that use an isolate scope. References: one, two
Suppose, I have a directive like this:
angular.module('MyModule').directive('MyDirective', function(User) {
return {
scope: {
name: '='
},
templateUrl: 'my-template.html',
link: function(scope) {
scope.User = User;
scope.doSomething = function() {
// Do something cool
};
}
};
});
<!-- my-template.html -->
<div>
User Id: {{ User.id }}
Name: {{ name }}
<button ng-click="doSomething()">Do it</button>
</div>
As you can see, there is no controller in this directive. But, to be able to leverage controllerAs and bindToController: true I have to have a controller.
Is the best practice to convert the linking function to a controller?
angular.module('MyModule').directive('MyDirective', function(User) {
return {
scope: {
name: '='
},
templateUrl: 'my-template.html',
bindToController: true,
controllerAs: 'myCtrl',
controller: function() {
this.User = User;
this.doSomething = function() {
// Do something cool
};
}
};
});
<!-- my-template.html -->
<div>
User Id: {{ myCtrl.User.id }}
Name: {{ myCtrl.name }}
<button ng-click="myCtrl.doSomething()">Do it</button>
</div>
My understanding is that directive's controller should be used as a mechanism to expose directive's API for a directive-to-directive communication.
Could anyone shed light on what's the best practice these days, having Angular 2.0 in mind?
I consider it best practice to move initialization code and/or exposing API functions inside of a directive's controller, because it serves two purposes:
1. Intialization of $scope
2. Exposing an API for communication between directives
Initialization of Scope
Suppose your directive defines a child scope (or inherits scope). If you initialize scope inside of your link function, then child scopes will not be able to access any scope variables defined here through scope inheritance. This is because the parent link function is always executed after the child link function. For this reason, the proper place for scope initialization is inside of the controller function.
Exposing a Controller API
Child directives can access the parent directive's controller through the 'require' property on the directive definition object. This allows directives to communicate. In order for this to work, the parent controller must be fully defined, so that it can be accessed from the child directive's link function. The best place to implement this is in the definition of the controller function itself. Parent controller functions are always called before child controller functions.
Final Thoughts
It is important to understand that the link function and the controller function serves two very different purposes. The controller function was designed for initialization and directive communication, and the linker function was designed for run-time behavior. Based on the intent of your code, you should be able to decide whether it belongs in the controller, or it belongs in the linker.
Should you move any code that initializes scope from the link function to the controller function?
Yes, that is one of the primary reasons that the controller function exists: to initialize scope, and allow its scope to participate in prototypical scope inheritance.
Should you move $watch handlers from the link function to the controller function?
No. The purpose of the link function is to hookup behavior and potentially manipulate the DOM. In the link function, all directives have been compiled, and all child link functions have already executed. This makes it an ideal place to hookup behavior because it is as close DOM ready as it can be (it is not truly DOM ready until after the Render phase).
I will start with your last sentence. It's all about how you want to write your angular code. If you want to stick with the guideline for writing good code for angular 1.x then don't even bother thinking too much about what is ideal. However, if you want to prepare for the next version of Angular, as well as, the upcoming web technologies, I would suggest that you start adopting the new concepts and adjust them to the way you write your code today. Bare in mind there is no right or wrong in this case.
Speaking about angular 2.0 and ES6, I would like to stress out that the notion of directives will be more in align with the Web Components technology.
In Angular 2.0 (according to the current design) will get rid of the complex way of defining directives; That is no more DDO. Thus I think it would be better if you start thinking in that way. A component will just have a View and a controller.
For example,
#ComponentDirective({
selector:'carousel',
directives:[NgRepeat]
})
export class Carousel{
constructor(panes:Query<CarouselItem>) {
this.items= panes;
}
select(selectedCarouselItem:CarouselItem) { ... }
}
The above code is written in AtScript (a superset of typescript and ES6), but you will be able to express the same thing in ES5, as well. You can see how simpler things will be. There in np such notion like link function or compile etc.
In addition, the view of the above component will be directly bound to the above class; So you can already find a similarity to the controllerAs syntax.
So in essence, I would suggest that you first look at the general idea behind Web Components, and how the future of the Web Developments might be, and then I think you would start writing Angular 1.x code with that in mind.
In summary, try to code in a way that favours the current version of Angular, but if you believe that there are some parts of your code that can embrace some concepts of the next version, then do it. I don't believe it will harm you. Try to keep it simple as the new version of Angular will be simpler.
I would suggest that you read the following posts:
https://www.airpair.com/angularjs/posts/component-based-angularjs-directives
http://eisenbergeffect.bluespire.com/all-about-angular-2-0/
https://www.airpair.com/angularjs/posts/preparing-for-the-future-of-angularjs
http://teropa.info/blog/2014/10/24/how-ive-improved-my-angular-apps-by-banning-ng-controller.html
UPDATE
(at the bottom I added a code/plnkr that shows the approach)
Apart from the article you mentioned: https://www.airpair.com/angularjs/posts/preparing-for-the-future-of-angularjs#3-3-match-controllers-with-directives, which basically not only advocates the pattern you are asking for, but component based front-end in general, I have found: http://joelhooks.com/blog/2014/02/11/lets-make-full-ass-angularjs-directives/ (it advocates Minimal use of the link function and use ui-bootstrap as an example where such a pattern has been used). I cannot agree more with both these articles.
Another thing about Angular2.0: no more $scope in angular2.0 -- https://www.youtube.com/watch?v=gNmWybAyBHI&t=12m14s, so surely if you can get rid of $scope as much as possible, then the transition should be smoother.
I made a small mistake as well:
Still, I prefer to define all functions in controller and just call
them via link's scope. Ideally it is just one call:
scope.init ctrl.init(/*args*/) (where ctrl is
directive's controller).
To some degree it is a matter of taste, but there are some valid reasons to keep the link function as thin as possible:
The logic in link function is not easily testable. Sure, you can compile the directive in your unit tests and test its behaviour, but the link function itself is a black box.
If you have to use controller (let say to inter directive communication), then you end up with two places where to put your code. It is confusing, but if you decide to have the link function thin, then everything that can be put in controller should be put in controller.
You cannot inject additional dependencies directly to the link function (you can still use those injected to the main directive function). There is no such a problem in case of controller's approach. Why it matters:
it keeps better structure of the code, by having the dependencies closer to the context where they are needed
people coming to angular with non-JS backgrounds have still problems how functional closure works in JS
So what has to be put in the link function:
Everything that needs to be run after the element has been inserted into DOM. If $element exposed $on('linked') event than basically this point is not valid.
Grabbing references to controllers require:ed. Again, if it was possible to inject them into the controller directly...
Still, I prefer to define all functions in controller and just call them via link's scope. Ideally it is just one call: scope.init.
Misko Hevery told a couple of times that DDO is far from being perfect and easy to understand and it evolved to what it is right now. I am pretty sure, that if the design decisions were made upfront then there would a single place to put the logic of the directive - as it will be in angular2.0.
Now answering your question if you should convert link function to a controller. It really depends on a number of criteria, but if the code is actively developed then probably it is worth to consider. My experience (and couple of people I talked about it) can be illustrated by this image:
About angular2.0 -- it is going to be a tectonic shift, so from that perspective it should not matter much, but still the controller's approach seems to be closer to the way directives/components are going to be declared in v2.0 via ES6 classes.
And as the last thing: To some degree it is a matter of taste, but there are some valid reasons to keep the CONTROLLER function thin as well (by delegating logic to services).
UPDATE -- PLNKR
PLNKR exemplifying the approach:
html
<input ng-model="data.name"/>
<top-directive>
<my-directive my-config="data">
</my-directive>
</top-directive>
js
var app = angular.module('plunker', []);
app.controller('MainCtrl', function($scope) {
$scope.data = { name : 'Hello, World'};
});
app.controller('MyCtrl', function($scope){
var self = this;
this.init = function(top){
this.topCtrl = top;
this.getTopName = top.getName.bind(top);
this.getConfigName = function(){return this.config.name};
console.log('initilizing', this, $scope, this.getConfigName, this.getTopName());
}
// if you want to $watch you have to inject $scope
// you have access to the controller via name defined
// in contollerAs
$scope.$watch('myCtrl.config', function(){
console.log('config changed', self.getConfigName());
}, true);
});
app.directive('topDirective', function(){
return {
controller : function(){
this.name = "Hello, Top World";
this.getName = function(){return this.name};
}
}
});
app.directive('myDirective', function(){
return {
require: ['myDirective', '^topDirective'],
controller : 'MyCtrl',
bindToController: true,
controllerAs: 'myCtrl',
template : '{{myCtrl.getConfigName() + " --- " + myCtrl.getTopName()}} ',
scope : {
config : "=myConfig",
},
link : function(scope, element, attrs, Ctrls){
Ctrls[0].init(Ctrls[1]);
}
}
});
As per the latest documentation this is still the recommended practice "use controller when you want to expose an API to other directives. Otherwise use link." I would like to hear from other people also and the approach they are using.
sharing the contents from here, (I dont have enough reputations to put it as comments)
“where do I put code, in ‘controller’ or ‘link’?”
Before compilation? – Controller
After compilation? – Link
Couple of things to note:
controller ‘$scope’ and link ‘scope’ are the same thing. The difference is paramaters sent to the controller get there through Dependency Injection (so calling it ‘$scope’ is required), where parameters sent to link are standard order based funcitons. All of the angular examples will use ‘scope’ when in the context, but I usually call it $scope for sanity reasons: http://plnkr.co/edit/lqcoJj?p=preview
the $scope/scope in this example is simply the one passed in from the parent controller.
‘link’ in directives are actually the ‘post-link’ function (see rendering pipeline below). Since pre-link is rarely used, the ‘link’ option is just a shortcut to setting up a ‘post-link’ function.
So, whats a real world example? Well, when I’m deciding, I go by this:
“Am I just doing template and scope things?” – goes into controller
“Am I adding some coolbeans jquery library?” – goes in link
Credit for the answer goes to jasonmore
There seems to be no way to provide data to an Angular controller other than through attributes in the DOM handled by directives (of which ngInit is a handy example).
I'd like to provide other "constructor" data, e.g. objects with functions to my
$scope.
Background: We have an existing dashboard-style single page application,
where each widget manages a <div>, and widget-instance-specific data
is provided as an object along with support functions, etc.. This object data
doesn't fit nicely into DOM attributes or ngInit calls.
I can't really come up with a better way to it than to have a global hash, and use an instance-specific unique key. Before calling angular.bootstrap(domElement, ['myApp']), we set up all "constructor" parameters in this global hash under the key and then use
<div ng-init='readInitialValuesFromHash("uniqueKey")'>...</div>
where readInitialValuesFromHash gets all its data from
globalHash["uniqueKey"] and stores what it needs it in $scope (possibly
just the "uniqueKey").
(What seems like an alternative is to use a directive and jQuery.data(), but jQuery.data uses a global hash behind the scenes)
Of course I can hide the global data in a function, but fundamentally still use
a singleton/global variable. This "global hash and pass key as param to ng init
trick" just seems like such a hack...
Am I missing something? Is there a better way, given that the
widget-instance-specific data is actually more complicated than suitable for
inserting in the DOM via directives/attributes due to the legacy dashboard
framework?
Are there dangers when putting complicated objects in the $scope as long as they aren't referenced by directives, {{}} or $scope.$watch() calls?
Angular's front page says:
Add as much or as little of AngularJS to an existing page as you like
So in light of that, how should I proceed?
EDIT: Comments have asked to make my question more clear. As an example of a non-trivial constructor parameter, assume I want to give this myObj to the controller, prototypical inheritance, function and all:
var proto = {
p1: "p1",
pf: function() {
return "proto"
}
};
function MyObj(ost) {
this.ost = ost;
}
MyObj.prototype=proto;
var myObj = new MyObj("OST");
So I have myObj, and I have a string:
<div ng-app='myApp' ng-controller="MyCtrl">....</div>
I put the string in the DOM, and call angular.bootstrap().
How to I get the real myObj object into MyCtrl's $scope for this <div>, not a serialized/deserialized version/copy of it?
Services is what you are looking for.
You can create your own services and then specify them as dependencies to your components (controllers, directives, filters, services), so Angular's dependency injection will take care of the rest.
Points to keep in mind:
Services are application singletons. This means that there is only one instance of a given service per injector. Since Angular is lethally allergic to global state, it is possible to create multiple injectors, each with its own instance of a given service, but that is rarely needed, except in tests where this property is crucially important.
Services are instantiated lazily. This means that a service will be created only when it is needed for instantiation of a service or an application component that depends on it. In other words, Angular won't instantiate services unless they are requested directly or indirectly by the application.
Services (which are injectable through DI) are strongly preferred to global state (what isn't), because they are much more testable (e.g. easily mocked etc) and "safer" (e.g. against accidental conflicts).
Relevant links:
Understanding Angular Services
Managing Service Dependencies
Creating Angular Services
Injecting Services into Controllers
Testing Angular Services
About Angular Dependency Injection
Example:
Depending on your exact requirements, it might be better to create one service to hold all configuration data or create one service per widget. In the latter case, it would probably be a good idea to include all services in a module of their own and specify it as a dependency of your main module.
var services = angular.module('myApp.services', []);
services.factory('widget01Srv', function () {
var service = {};
service.config = {...};
/* Other widget01-specific data could go here,
* e.g. functionality (but not presentation-related stuff) */
service.doSomeSuperCoolStuff = function (someValue) {
/* Send `someValue` to the server, receive data, process data */
return somePrettyInterestingStuff;
}
...
return service;
}
services.factory('widget02Srv', function () {...}
...
var app = angular.module('myApp', ['myApp.services']);
app.directive('widget01', function ('widget01Srv') {
return function postLink(scope, elem, attrs) {
attrs.$set(someKey, widget01Srv.config.someKey);
elem.bind('click', function () {
widget01Srv.doSomeSuperCoolStuff(elem.val());
});
...
};
});
ExpertSystem's answer gave me the hint that I needed. A separate controller instance for each widget. Note how the constructorParameter (==myObj) gets inserted into the controller.
function creatWidgetInstance(name) {
....
var controllerName = name + 'Ctrl';
// myObj comes from the original question
var constructorParameter = myObj;
widgetApp.controller(controllerName, function($scope) {
$scope.string = constructorParameter;
});
....
newWidget = jQuery(...);
newWidget.attr('ng-controller', controllerName);
angular.bootstrap(newWidget[0], ['widgetApp']);
....
}
See it working in a plunker
Perhaps a more beautiful solution is with a separate service too, as in:
function creatWidgetInstance(name) {
....
var controllerName = name + 'Ctrl';
var serviceName = name + 'Service';
// myObj comes from the original question
var constructorParameter = myObj;
widgetApp.factory(serviceName, function () {
return { savedConstructorParameter: constructorParameter };
});
widgetApp.controller(controllerName,
[ '$scope', serviceName, function($scope, service) {
$scope.string = service.savedConstructorParameter;
}
]
);
....
newWidget = jQuery(...);
newWidget.attr('ng-controller', controllerName);
angular.bootstrap(newWidget[0], ['widgetApp']);
....
}
See this in a working Plunker
The answer to the question requires backtracking a few assumptions. I thought that the only way to setup $scopewas to do it on a controller. And so the question revolves around how to "provide data to an Angular controller other than through attributes in the DOM handled by directives".
That was misguided.
Instead, one can do:
var scope = $rootScope.$new();
// Actually setting scope.string=scope makes for a horrible example,
// but it follows the terminology from the rest of the post.
scope.string = myObj;
var element = $compile(jQuery('#widgetTemplate').html())(scope);
jQuery('#widgets').append(element);
See this Plunker for a working example.
I want to inject instances of a class. From this thread it looks like services return new serviceArgFunction, which is what I want. https://groups.google.com/forum/#!msg/angular/56sdORWEoqg/VxECXKbn3gsJ
But I can't seem to get it to work. For some reason, my two instances of share state. Can anyone help me figure out what I'm doing wrong?
http://jsfiddle.net/kTjMy/5/
var Klass = function() {
this.count = 0;
this.getAndIncCount = function() {
this.count += 1;
return this.count;
};
};
app.service('service', Klass);
You can use a factory that returns the constructor for your class:
app.factory('myKlass', function() {
return Klass
});
Even more simply, if Klass is defined elsewhere, you can use value:
app.value('myKlass', Klass);
Either way, inject it as normal.
function CtrlA($scope, myKlass)
{
new myKlass();
}
See this jsFiddle.
[Edit] See also this Google Groups post and this associated example.
To make it clear I created a little Plunker.
It has a Service and a Factory.
Service and Factory have a value and setters and getters.
Both are injected into Controllers A and B.
If You change the value of the Service in Controller A, this change takes also place in Controller B, because the service is a Singleton.
But when You change the value in the Factory in the Controller B, this affects only B because the change takes only place in the instance that is created in B.
Enjoy!
Maximilian - thank you for the great example.
I converted this to JSFiddle, as a place to experiment with another design pattern that I wanted to dig into.
Why is it that swapping the provider type from "service" to "factory" still seems to work?
It seems more about how the provider is created i.e. using 'new' versus just referencing it directly.
Also, within the service, is there a design pattern as to why a service should implement the "this" keyword, as opposed to using using return { myAccessor : function () { return val; } }
See
http://jsfiddle.net/jeffsteinmetz/XF69p/
In this jsfiddle, you can change one line of the code (line 23), and it still works, the line of code can be either:
App.service('MyService', function() {
or
App.factory('MyService', function() {
Why do these both work?
It seems more about how you reference the service with "new"
var myInstance = new MyFactory();
Which is different than just calling it directly
MyService.getVal()
Any angular folks care to lay out the best practices and reasoning behind this:
when to use 'new' and when you don't need new
why use the 'this' reference approach to define your provider instead of return { accessorName : function}
why do both factory or service work in the above example?