How to properly save self reference with ES6 classes? - angularjs

Honestly, I'm not sure of what is the cause for the behavior: systemjs, babel or my own fault. I'm using class for custom control controller and saving class reference in self variable. Apparently that gets overriden by any subsequent controller instances.
I created a simple repository to demonstrate:
clone, install, run live-server or your preferred server. You will see 2 buttons, each is a custom control. Clicking on a button only affects one control.
https://github.com/alexkolt/selfIsThis
How can I get this working with ES6 class?

I should have posted the code, sorry.
The reason you'd want to save reference to self is for example in callbacks calling this might result in a different reference.
I was trying to do this:
var self;
class Test {
constructor(dependency) {
self = this;
self.dependency = dependency;
}
method() {
self.dependency().then(value => self.property = value);
}
}
Like it was mentioned before the self becomes shared when declared outside of the module. I didn't realize that would happen as files would be wrapped in a closure. Joe Clay answer is correct, but to do what I was trying to do self needs to be declared in every method that needs it.
class Test {
constructor(dependency) {
this.dependency = dependency;
}
method() {
var self = this;
this.dependency().then(value => self.property = value);
}
}

You're not really using ES6 classes right. You don't need to save a reference to this - just access it directly in class methods. The way you have it at the minute, all your instances of CustomControlController are sharing a single self variable.
class CustomControlController {
constructor() {
this.value = 0;
}
click() {
var newValue = this.value * 2;
this.value = newValue;
}
}
export default CustomControlController;

Related

Setting context of "this" from another typescript class, using AngularJS dependency injection

I'm using a TypeScript class to define a controller in AngularJS:
class TrialsCtrl {
constructor(private $scope: ITrialsScope, private ResourceServices: ResourceServices) {
this.loadTrials();
}
loadTrials() {
console.log("TrialsCtrl:", this);
this.Trial.query().then((result) => {
this.$scope.Trials = result;
});
}
remove(Trial: IRestTrial) {
this.ResourceServices.remove(Trial, this.loadTrials);
}
}
angular.module("app").controller("TrialsCtrl", TrialsCtrl);
I'm refactoring common controller methods into a service.
class ResourceServices {
public remove(resource, reload) {
if (confirm("Are you sure you want to delete this?")) {
resource.remove().then(() => {
reload();
});
}
}
}
angular.module("app").service("ResourceServices", ResourceServices);
The console log shows that this is referencing the window context when I want it to be TrialsCtrl. My problem is that the reload() method needs to run in the context of TrialsCtrl, so that it can access this.Trial and this.$scope. How can I tell the reload() method to set this as the TrialsCtrl? Or is there some other workaround I should be using for this kind of thing?
Have you tried:
this.ResourceServices.remove(Trial, this.loadTrials.bind(this));
or
this.ResourceServices.remove(Trial, () => this.loadTrials());
For methods that are supposed to be passed as callbacks (as with this.loadTrials) it is preferable to define them as arrows,
loadTrials = () => { ... }
So they keep the context whether Function.prototype.bind is used or not.
Alternatively, a decorator may be used on the method (like core-decorators #autobind) to bind a method while still defining it on class prototype:
#autobind
loadTrials() { ... }

Why do i have to re-declare properties in typescript angular controller functions

export interface IFooModel {
foo:string;
fooFunction(fooProp:string):void;
}
export class FooCtrl implements IFooModel {
constructor(public foo:string){
}
fooFunction(fooProp:string):void{
}
}
The code above is fairly standard. My question is , when i want to access foo:string in the function i have to do this
fooFunction(fooProp:string):void{
var fooAgain = this.foo;
// Pretend i set it up properly for $mdDialog to work
this.$mdDialog.show(options).then(function(answer: boolean) {
if (answer) {
// fooAgain works
// this.foo does not work
}
}
Why do i have to set this.foo to a variable in order to access it inside another function , instead of just writing this.foo ? In some functions i end up for about 4 variables declarations that are already declared in the constructor. Is there maybe a better way to this? I get the feels that there is too much repeat code in the controller.
Yes this is a problem in Javascript, but thankfully in TypeScript this problem is no more thanks to fat arrows! Yay!
Fat arrows are like anonymous functions but handle the this variable for you.
Let me show you:
fooFunction(fooProp:string):void {
// Pretend i set it up properly for $mdDialog to work
this.$mdDialog.show(options).then((answer: boolean) => {
if (answer) {
this.foo = "";
}
});
}
Using fat arrows this will now compile to this in JS:
FooCtrl.prototype.fooFunction = function (fooProp) {
var _this = this;
// Pretend i set it up properly for $mdDialog to work
this.$mdDialog.show(options).then(function (answer) {
if (answer) {
_this.foo = "";
}
});
};
So Typescript automatically creates a _this variable for you, so that you no longer have the problem. Pretty neat if you ask me.
Here's the documentation for Arrow functions:
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions
The only reason to place the value in a local variable prior to calling a function is because you expect the class to go out of scope (i.e. something will happen to change the scope, such as a callback or asynchronous operation).
By putting the value in a local variable it becomes part of the closure for the function and the value is stored alongside the function itself.
This is one of the trickiest aspects of JavaScript - scope is kinda funky.
There are other options to solve this problem, including fat arrows...
() => {
// this.foo is now preserved
}
Or call / apply which allow you to set the scope.

this point set to null using afterSelectionChange in ngGrid

I'm writing an application using angular and typescript.
I'm using ng-grid and I have to handle the afterSelectionChange event.
I tried to set the event handler in two ways
this.$scope.settoriGridOptions.afterSelectionChange = this.afterSelectionChange;
where this.afterSelectionChange is a method of the controller class,
and
this.$scope.settoriGridOptions.afterSelectionChange = (... ) => {};
including the code inside, but in both cases the this pointer is incorrect and I cannot access to the services of the controller.
how can I fix this?
after a more tests and reading a few articles I see that the problem is the implicit passing of the this pointer as parameter in the function call.
if I write
$scope.filtroSoluzione = this.filtroSoluzione;
when called the this pointer is set to null, but if I write
$scope.filtroSoluzione = () => { return this.filtroSoluzione() };
or
$scope.filtroSoluzione = () => { .. inline code ... };
the this pointer I set correctly.
How can I have a more consistent behavior? I don't like to write always the code inside because this makes the class harder to read and navigate
thanks,
Luca
Thanks for the extra information in your edits, I now see the problem.
class foo {
public afterSelectionChange = () => {
console.log(this);
}
}
When you declare your function like I did above, your this is the instance instead of what you are seeing know because it captures the this variable. It comes with a cost though, because now it creates a new afterSelectionChange function for every instance of your class. In this case I think it is still what you want though.
var foo = (function () {
function foo() {
var _this = this;
this.afterSelectionChange = function () {
console.log(_this);
};
}
foo.prototype.baz = function () {
console.log(this);
};
return foo;
})();
In the above code-gen you can see the difference when declaring the function with name = () => {} and the normal way.
Another solutions might be this:
this.$scope.settoriGridOptions.afterSelectionChange = this.afterSelectionChange.bind(this);
But I don't find that really nice either... (this should work with the normal public afterSelectionChange() {} declaration you are used to.

Extending Backbone Collections to add logic, with custom methods, is a bad practice?

Usually I find my self needing to write an object with a specific functionality that it is a set of models.
Finally I extend a collection and add more functions that works with its model.
I think is better show you an example:
My app has a set of permissions, related with the user and/or the version of the platform.
var Permissions = Backbone.Collection.extend({
model: Permission,
hasAccess: function (moduleCode) {
....
},
allowAccess: function (moduleCode) {
....
},
...
With that methods I change the format of a property of a permission (the model). (My permissions are a concatenation of code with an string that identify the type of permission.)
A workmate tells me that it is wrong. In .NET he creates a class and he adds a private list and makes the changes to it. He does not inherit the list and changes it.
He would make a model and inside it he would add a collection property
this.set("permissionsCollection", new Backbone.Collection.extend({model: Permission}))
[Comment: I don't understand why he creates properties of everything, I think in his case it is not needed.] -> But this is another question
I think in a different way. I know the Collection has internally that list. I have a great potencial in Backbone.Collections, why do I have to use a model that it is not necessary? If I don't need that encapsulation... I think that it is not necessary, he is overprogramming in my opinnion.
Am I wrong? Did I not know how to use BackboneJS Collections?
Thank you in advance.
At the beginning I had something called helper with similar methods:
findAttr: function (model, name) {
var attrs = model.get('app_attrs');
if (attrs !== undefined) {
return this.findByAttrName(attrs, name);
}
},
findByAttrName: function (array, name) {
return _.find(array, function(a) {
if (a.attrName === name) {
return a;
}
});
}
The view code was more awkward:
render: function () {
var attr = helper.findAttr(this.model, 'user');
...
return this;
}
The only logical solution was to move these methods into the model (this.model in the above case). After refactoring I've got:
render: function () {
var attr = this.model.findAttr('user');
...
return this;
}
which is of course more readable than the previous solution.

Backbone.Events context issue in Appcelerator Titanium

I have a custom library in my Titanium Mobile (3.1.0 GA SDK) project that looks something like this:
// lib/MyObject.js
function MyObject
{
var self = this;
_.extend(self, Backbone.Events);
this.trigger('myEvent');
}
module.exports = MyObject;
In another part of my application, I make the class available globally:
Alloy.Globals.MyObject = require('MyObject');
And in a controller, I instantiate it:
var myObj = new Alloy.Globals.MyObject();
That object gets passed around a bit, until finally an event listener is added:
// In another controller
myObj.on('myEvent', function() {
console.log('My event happened!');
};
Unfortunately, log command never gets called. If I add an event listener within the MyObject function, it works fine. But it won't work when called from outside the object.
I would just assume that there's a bug in there, or the object is getting passed by value instead of reference, except for this. If I change the class definition to the following:
// lib/MyObject.js
function MyObject
{
var self = this;
_.extend(self, Backbone.Events);
var old_on = this.on;
this.on = function(a, b, c) {
return old_on.call(self, a, b, c);
};
this.trigger('myEvent');
}
module.exports = MyObject;
...everything works. Somehow the on function is not getting the correct context, but I can't for the life of me figure out why. Anyone have insight into what's going on?
Hmm, updating to the 3.1.1.GA SDK version fixed it. Must've been a bug in Titanium.

Resources