Typescript this class method

TypeScript and ‘this’ in class methods

At Checkpad we are moving JavaScript code to TypeScript. Apart from some initial “take-off” issues like finding, modifying and/or writing missing .d.ts files for libraries, or getting our build pipeline to work, the process was pretty smooth. A few months into that, I’ve discovered some road bumps and will share one today.

I’m currently writing a web frontend for a new feature of our product using TypeScript and React (TypedReact). While working with callbacks and class methods I’ve discovered a flaw (or more a missing feature) in the compiler. Consider the following code:

class Foo  private bar: string = "Bar"; logBar(): void  console.log("Bar's value is: " + this.bar); > > // many javascript frameworks rebind the this context for callbacks, // see for example jQuery's $("foo").click or React's onClick will bind to the // DOM element firing the event function fireCallback(cb: (() => any)): void  let someObj =  hello: "42" >; cb.call(someObj); > let x = new Foo(); fireCallback(x.logBar);

The naive expected output would be: Bar’s value is: Bar . Let’s compile the snippet and run it:

$ tsc --version message TS6029: Version 1.5.0-beta $ tsc --noImplicitAny main.ts && node main.ts Bar's value is: undefined 

That’s not the expected result! this.bar is undefined . Looking at the code again it’s quite obvious why this happened: We can change the context of this and bypass the TypeScript type checker. The type system does not track the type of this correctly. Luckily there are suggestions to fix that (see Github Issue #3694 for example), but these will take a while to ripe. That’s why I would suggest that the TypeScript compiler automatically performs a transformation on class methods as arguments to preserve the this context like so:

fireCallback((. args: any[]) => x.logBar.call(x, args));

This should be okay, be cause inside a method the compiler assumes that this is of the classes type so there’s no way to interact with later bound this contexts anyhow.

I’ve filed an issue, let’s see what the community and the typescript team thinks!

Update July 21, 2015

Unfortunately the ES6 standard seems to define “broken” this semantics. TypeScript wants to strictly comply to the standard, so they probably will not change anything here (soon). We came up with a better proposal to fix the wrong this semantics which you could use as coding convention in your code:

class Foo  private bar: string = "Bar"; logBar = () =>  console.log("Bar's value is: " + this.bar); > >

This is about 25% slower when called, but at least you get expected this semantics. Hopefully TypeScript will add proper this -typing to their type system soon.

(functional) programming and more
Opinions are my own.

Источник

this in JavaScript and TypeScript

Sometimes when writing JavaScript, I want to shout “This is ridiculous!”. But then I never know what this refers to.

If there is one concept in JavaScript that confuses people, it has to be this . Especially if your background is a class-based object-oriented programming languages, where this always refers to an instance of a class. this in JavaScript is entirely different, but not necessarily harder to understand. There’re a few basic rules, and about as many exceptions to keep in mind. And TypeScript can help greatly!

this in regular JavaScript functions #

A way I like to think about this is that in regular functions (with the function keyword or the object function short-hand), resolve to “the nearest object”, which is the object that they are bound to. For example:

const author =  
name: "Stefan", 
// function shorthand 
hi()  
console.log(this.name); 
>,
>;

author.hi(); // prints 'Stefan'

In the example above, hi is bound to author , so this is author .

JavaScript is flexible, you can attach functions or apply functions to an object on the fly.

const author =  
name: "Stefan", 
// function shorthand 
hi()  
console.log(this.name); 
>,
>;

author.hi(); // prints 'Stefan'

const pet =  
name: "Finni", 
kind: "Cat",
>;

pet.hi = author.hi;

pet.hi(); // prints 'Finni'

The “nearest object” is pet . hi is bound to pet .

We can declare a function independently from objects and still use it in the object context with apply or call :

function hi()  
console.log(this.name);
>

const author =  
name: "Stefan",
>;

const pet =  
name: "Finni", 
kind: "Cat",
>;

hi.apply(pet); // prints 'Finni'
hi.call(author); // prints 'Stefan'

The nearest object is the object we pass as the first argument. The documentation calls the first argument thisArg , so the name tells you already what to expect.

apply vs call #

What’s the difference between call and apply ? Think of a function with arguments:

function sum(a, b)  
return a + b;
>

With call you can pass the arguments one by one:

null is the object sum should be bound to, so no object.

With apply , you have to pass the arguments in an array:

An easy mnemonic to remember this behaviour is array for apply, commas for call.

bind #

Another way to explicitly bind an object to an object-free function is by using bind

const author =  
name: "Stefan",
>;

function hi()  
console.log(this.name);
>

const boundHi = hi.bind(author);

boundHi(); // prints 'Stefan'

This is already cool, but more on that later.

Event listeners #

The concept of the “nearest object” helps a lot when you work with event listeners:

const button = document.querySelector("button");

button.addEventListener("click", function ()  
this.classList.toggle("clicked");
>);

this is button . addEventListener sets one of many onclick functions. Another way of doing that would be

button.onclick = function ()  
this.classList.toggle("clicked");
>;

which makes it a bit more obvious why this is button in that case.

this in arrow functions and classes #

So I spent half of my professional JavaScript career to totally understand what this refers to, just to see the rise of classes and arrow functions that turn everything upside down again.

Here’s my most favorite meme on this (click to expand)

Arrow functions always resolve this respective to their lexical scope. Lexical scope means that the inner scope is the same as the outer scope, so this inside an arrow function is the same as outside an arrow function. For example:

const lottery =  
numbers: [4, 8, 15, 16, 23, 42], 
el: "span", 
html()  
// this is lottery 
return this.numbers 
.map( 
(number) => 
//this is still lottery 
`$this.el>>$number>$this.el>>` 
) 
.join(); 
>,
>;

Calling lottery.html() gets us a string with all numbers wrapped in spans, as this inside the arrow function of map doesn’t change. It’s still lottery .

If we would use a regular function, this would be undefined, as there is no nearest object . We would have to bind this :

const lottery =  
numbers: [4, 8, 15, 16, 23, 42], 
el: "span", 
html()  
// this is lottery 
return this.numbers 
.map( 
function (number)  
return `$this.el>>$number>$this.el>>`; 
>.bind(this) 
) 
.join(""); 
>,
>;

In classes, this also refers to the lexical scope, which is the class instance. Now we’re getting Java-y!

class Author  
constructor(name)  
this.name = name; 
>
 
// lexical, so Author 
hi()  
console.log(this.name); 
>
 
hiMsg(msg)  
// lexical, so still author! 
return () =>  
console.log(`$msg>, $this.name>`); 
>; 
>
>

const author = new Author("Stefan");
author.hi(); //prints '
author.hiMsg("Hello")(); // prints 'Hello, Stefan'

unbinding #

Problems occur if you accidentally unbind a function, e.g. by passing a function that is bound to some other function or storing it in a variable.

const author =  
name: "Stefan", 
hi()  
console.log(this.name); 
>,
>;

const hi = author.hi();
// hi is unbound, this refers to nothing
// or window/global in non-strict mode
hi(); // 💥

You would have to re-bind the function. This also explains some behaviour in React class components with event handlers:

class Counter extends React.Component  
constructor()  
super(); 
this.state =  
count: 1, 
>; 
>
 
// we have to bind this.handleClick to the 
// instance again, because after being 
// assigned, the function loses its binding . 
render()  
return ( 
> 
this.state.count> 
button onClick=this.handleClick.bind(this)>>+/button> 
/> 
); 
>
 
//. which would error here as we can't 
// call `this.setState` 
handleClick()  
this.setState(( count >) => ( 
count: count + 1, 
>)); 
>
>

this in TypeScript #

TypeScript is pretty good at finding the “nearest object” or knowing the lexical scope, so TypeScript can give you exact information on what to expect from this . There are however some edge cases where we can help a little.

this arguments #

Think of extract an event handler function into its own function:

const button = document.querySelector("button");
button.addEventListener("click", handleToggle);

// Huh? What's this?
function handleToggle()  
this.classList.toggle("clicked"); //💥
>

We lose all information on this since this would now be window or undefined . TypeScript gives us red squigglies as well!

We add an argument at the first position of the function, where we can define the type of this .

const button = document.querySelector("button");
button.addEventListener("click", handleToggle);

function handleToggle(this: HTMLElement)  
this.classList.toggle("clicked"); // 😃
>

This argument gets removed once compiled. We now know that this will be of type HTMLElement , which also means that we get errors once we use handleToggle in a different context.

// The 'this' context of type 'void' is not
// assignable to method's 'this' of type 'HTMLElement'.
handleToggle(); // 💥

ThisParameterType and OmitThisParameter #

There are some helpers if you use this parameters in your function signatures.

ThisParameterType tells you which type you expect this to be:

const button = document.querySelector("button");
button.addEventListener("click", handleToggle);

function handleToggle(this: HTMLElement)  
this.classList.toggle("clicked"); // 😃 
handleClick.call(this);
>

function handleClick(this: ThisParameterTypetypeof handleToggle>)  
this.classList.add("clicked-once");
>

OmitThisParameter removes the this typing and gives you the blank type signature of a function.

// No reason to type `this` here!
function handleToggle(this: HTMLElement)  
console.log("clicked!");
>

type HandleToggleFn = OmitThisParametertypeof handleToggle>;

declare function toggle(callback: HandleToggleFn);

toggle(function ()  
console.log("Yeah works too");
>); // 👍

ThisType #

There’s another generic helper type that helps defining this for objects called ThisType . It originally comes from the way e.g. Vue handles objects. For example:

var app5 = new Vue( 
el: "#app-5", 
data:  
message: "Hello Vue.js!", 
>, 
methods:  
reverseMessage()  
// OK, so what's this? 
this.message = this.message.split("").reverse().join(""); 
>, 
>,
>);

Look at this in the reverseMessage() function. As we learned, this refers to the nearest object, which would be methods . But Vue transforms this object into something different, so you can access all elements in data and all methods in methods (eg. this.reverseMessage() ).

With ThisType we can declare the type of this at this particular position.

The Object descriptor for the code above would look like this:

type ObjectDescriptorData, Methods> =  
el?: string; 
data?: Data; 
methods?: Methods & ThisTypeData & Methods>;
>;

It tells TypeScript that within all functions of methods , this can access to fields from type Data and Methods .

Typing this minimalistic version of Vue looks like that:

declare const Vue: VueConstructor;

type VueConstructor =  
newD, M>(desc: ObjectDescriptorD, M>): D & M
)

ThisType in lib.es5.d.ts itself is empty. It’s a marker for the compiler to point this to another object. As you can see in this playground, this is exactly what it should be.

Bottom line #

I hope this piece on this did shed some light on the different quirks in JavaScript and how to type this in TypeScript. If you have any questions, feel free to reach out to me.

I’ve written a book on TypeScript! Check out TypeScript in 50 Lessons, published by Smashing Magazine

Источник