Discussion on: Rethinking JavaScript: The complete elimination and eradication of JavaScript's this.

[jose-torres-chang]

I had face a bad time debugging working with React, when the error was just forgot to bind this, but nothing really bad. But with TypeScript works the same way? Working with TS never had any problem.

[JavaScript Joel]

TypeScript is awesome. It definitely helps with this issues. The big problem of this in plain JavaScript is that you can never be sure what it really is. And your code may work differently based on how other people use it.

These two pieces of code could yield different results because this becomes unintentionally rebound to a different context.

const cat = {
  sound: 'meow',
  speak: function() { return this.sound; }
}

const logSound1 = animal => console.log(animal.speak())
const logSound2 = ({ speak }) => console.log(speak())

logSound1(cat) //=> "meow"
logSound2(cat) //=> Cannot read property 'sound' of undefined.

So instead of worrying about what this is all the time, let's just get rid of this completely and we never have to guess again.

[jose-torres-chang]

Oh, thanks for taking the time, to explain to me, to make it pretty clear. I used to think, problem was just about scope.

[JavaScript Joel]

It is actually. it's just that your scope can change when you do not expect it to change.

[jose-torres-chang]

So, is there any other options to avoid using this, that are native to JS? I know one of the quickest ways is var self = this, but not about anything that do not involves a variable. And one of your past comments, wake up my curiosity, if TypeScript is a superset of JS, what it does to work aroun with this issues?

[JavaScript Joel]

TypeScript doesn't fix all this issues.

If you check out the REPL at typescriptlang.org/play/ and enter this code:

const cat = {
    sound: 'meow',
    speak() { return this.sound }
}

const speak = cat.speak
speak()

You'll find it still has problems with this.

My solution to avoiding this is to write JavaScript functionally and not to mix data and functions together into classes.

I would instead write the above like this:

const cat = {
  sound: 'meow',
}

const speak = ({ sound }) => sound
speak(cat) //=> "meow"

[jose-torres-chang]

Although I can see what you are pointing, what is difficult, is to find the best way to avoid using this in a real application. Thanks a lot, this has been one of the most significant discussion this year.

[JavaScript Joel]

That is because you have been taught to use this. With OOP, you are pretty much stuck with this (unless of course you use nothis). When you learn functional reactive programming, you'll find this to no longer be necessary and magically this just vanishes from your codebase.

Check out one of my projects here github.com/joelnet/bitcoin-all-tim.... This is a real world application. It follows what I preach from How I rediscovered my love for JavaScript after throwing 90% of it in the trash.

You won't find any references to this, var, let, if, switch, for, the function keyword or other staples of classic javascript programs.

[Jim Przybylinski]

If you use typescript and modify the cat speak code to use an explicit if, you get a compile error.

const cat = {
    sound: 'meow',
    speak(this: {sound: string}) { return this.sound }
}

const speak = cat.speak
speak() // <= Compile error: void is not assignable to { sound: string }.

[JavaScript Joel]

It's pretty nice that this will happen at compile time and not runtime.