Closed
Description
Search Terms
bind, this, callback
Suggestion
Emit a warning or error when a method meets these conditions:
- The method is implemented using standard method syntax.
- The method needs
this
context to be preserved (uses thethis
keyword). - The method is passed as a callback to another function.
Use Cases
The standard syntax for defining methods is clean, concise, familiar, and (arguably) preferable to everyone. However, methods defined using this common syntax will not preserve the context of this
when passed as a callback to another function. This mistake is easy to make, yet perfectly legal!
class Example {
private _privateVar: any = "Hello World!";
/**
* Method syntax is the standard syntax we all know and love.
* The problem is `this` context won't be preserved if used as a callback.
*/
public methodSyntax(): any {
return this._privateVar;
}
/**
* Instance syntax solves the `this` problem, but it comes with other drawbacks/trade offs.
*/
public instanceSyntax = () => {
return this._privateVar;
}
}
function doSomething(func: Function): any {
return func();
}
let obj = new Example();
let result1 = doSomething(obj.methodSyntax); // undefined (OOPS!)
let result2 = doSomething(() => obj.methodSyntax()); // "Hello World!"
let result3 = doSomething(obj.methodSyntax.bind(obj)); // "Hello World!"
let result4 = doSomething(obj.instanceSyntax); // "Hello World!"
Examples
Using the above example, I'd love to see the compiler offer the suggestions made in this page. Something like this
let obj = new Example();
// Error: Method using `this` context should not be used as callback.
// Consider:
// - Refactoring the method as an instance method.
// - Surrounding the method argument with a local anonymous function.
// - Using the `bind` function.
let result1 = doSomething(obj.methodSyntax);
let result2 = doSomething(() => obj.methodSyntax()); // OK
let result3 = doSomething(obj.methodSyntax.bind(obj)); // OK
let result4 = doSomething(obj.instanceSyntax); // OK
Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript / JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. new expression-level syntax)