Replacing ‘that = this’ assignments in JavaScript with Arrow Functions
dbwriteups.wordpress.com
dbwriteups.wordpress.com
Since this is nearly always the pattern that's followed in the class pattern, I nearly always alias `this`, if needed, to the lowercase instance name or some short identifier that semantically maps to "an instance of the class". It gets you instantly out of both the problem of "I already used `that` as an identifier, now what?" as well as providing some nice context to what you're working on if you happen to be scrolled beyond the function/constructor name.
function SomeClass(arg1, secretArg) {
var someClass = this; // or `var sc = this`, more often these days
// Hopefully do something more interesting than this...
someClass.arg1 = arg1;
someClass.method = function(foo) {
someClass.bar = foo;
// Do something with the "private" param via closure.
secretArg.count++;
};
}
1) You're creating a new function instance for `SomeClass.method` every single time you create an instance of SomeClass. This will slow down construction.
2) `method` is an instance property, not a prototype property, and so takes up more memory for a reference per instance, plus the memory of the function instance.
3) In that function instance, you're closing over the references to `someClass` and `arg1` even though they're already available in `method` as `this` and `this.arg1`, also increasing the memory of instances.
4) Setting method will cause an unnecessary hidden-class transition.
If you really want to hide `secretArg`, use a WeakMap:
const secrets = new WeakMap();
class SomeClass {
constructor(arg1, secretArg) {
this.arg1 = arg1;
this.bar = undefined;
secrets.set(this, secretArg);
}
method(foo) {
this.bar = foo;
const secret = secrets.get(this);
secret.count++;
}
}
In the grand scheme of all the allocation and computation taking place in my applications, these concerns are very far down the line.
Now, if you happen to be creating an application or framework that for some reason has to do a whole lot of allocating and might be meaningfully and measurably affected by such issues, then by all means use prototype "methods" when it will make a difference.
Personally, code clarity is much more important than making sure my application starts microseconds faster and allocates several bytes fewer per instance when there are only going to be ~10s of instances ever created.
Many people, especially newcomers, believe that just because their code initializes a class only N times it's being instanced exactly N times. This is false more often than not, especially in server environments.
This makes sense if it's only you working on a project, but it would be pretty confusing and weird for someone new to join.
If anything, ES6 lambdas add yet another way of interpreting `this` because while it is a function, it's not functionally scoped. Even better, a lambda is a function but `call` and `apply` are interpreted differently [1] since `this` is not bound. If you ever need to use `call` or `apply`, you'll have to know exactly how the called code is implemented to avoid bugs.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
SomeClass = function (arg1) {
// Hopefully do something more interesting than this, indeed. :)
this.arg1 = arg1;
};
/**
* Assigns foo to the instance variable bar.
*/
SomeClass.prototype.method = function (foo) {
// Hopefully you do something more interesting than this, too!
this.bar = foo;
};
someClass = new SomeClass();
someclass.method(foo);
someClass = new SomeClass();
var handler = someclass.method.bind(someclass);
$('.link').click(handler); // using jQuery as easy-to-read DOM shorthand; it's not required
/**
* Creates a click handler for <a class="link"> elements.
*/
SomeClass.prototype.init = function () {
var handler = this.method.bind(this);
$('.link').click(handler);
};
Also, the ES2015 class keyword is syntactic sugar for the best of both worlds of the prototype pattern, combined with the private variable support of the class pattern. It does the right thing with both `this` and `super` (which is possible but tough with the prototype pattern and nearly impossible or at least crazy tough to do right with the class constructor pattern) and is as useful/important to replacing that = this/self = this antipatterns as arrow functions are.
Pervasive usage of `bind` drives me mad. It can patch over problems if you're using it locally, but if a function is being passed around, it invisibly has different behavior from a normal function with dynamic `this`. It also is quite noisey, in my opinion.
Using methods of an object to contain the sequences of an async process is handy. But it's not as flexible as promises, because it only works if the async process is self-contained. Promises are far more composable, which is important for modular processes. And with `async` functions, they allow native flow control structures to cross async boundaries. By comparison, a the methods+callbacks approach feels like programing with GOTO in BASIC.
Conventions (like prefixing with _) are great, but they can only help loosely enforce encapsulation and provide no form of real privacy.
Personally, I think sticking to one pattern makes more sense than having to switch patterns and deal with the inconsistency of that depending on your performance use-case. I personally think the prototype pattern is nicer, too.
I very frequently want to pass methods around as callbacks and almost never want my functions re-bound as methods on alternative objects. The only times I can think of that I want to re-bind is when I'm writing library code.
Python has an interesting solution to this, which is a lot more complicated - it has a more generic concept of "descriptors" that's used to wrap functions into magic sauce that makes them methods, taking care of "self" etc - but with most of that complexity hidden from either side (definition and invocation).
You can do it yourself:
>> def x(*args): print(args)
>> new_func = a.__get__('silly sausage')
>> new_func()
('silly sausage',)
Here are the docs if anyone is interested: https://docs.python.org/3/howto/descriptor.html
Dynamic `this` assumes we want methods to be portable between objects. That's nice and all, but I can't think of the last time I thought it was the best approach to solving a problem in real application code.
It can be argued that a better way to do this is to just have freestanding generic functions that dispatch on the first argument (or better yet, multimethods that dispatch on as many as you want), and then just consider x.f(y) to be a syntactic sugar for f(x, y). But generics themselves are fairly complicated, and many people don't like that extra complexity.
Are there sweet JS refactoring tools that a VS Code using, typescript preferring dev like myself should be using? I'd really like to drop this style if I can.
function Foo() {
return function() {
(this super).Bar();
}
}
...a new empty object is created, (let’s name it newObj) and the function is invoked on that object,
like say, newObj.Person() in this case.
(new Function).Function
=> undefinedIf anything, it's more like:
var newObj = Object.create(Person.prototype)
var result = Person.call(newObj)
if (typeof result === 'object' && result !== null) return result
return newObj
var p = {};
Person.call(p); // calls Person with p as this
Here's a good video on the subject https://www.youtube.com/watch?v=ImwrezYhw4w
This is one area where typescript (or es7) does it better with async functions where arrow operators are permitted.
if you are a node developer, title can be: something very banal you've been using for ages.