DEV Community

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

Collapse
zeddotes profile image
zeddotes

I think finding a nothis or fixthis in your code is far more terrifying than dealing with this. Interesting read nonethless.

Collapse
joelnet profile image
JavaScript Joel Author

The project is early and in need of polish. It is also in need of contributors like you to provide these suggestions.

Based on feedback I have created a helper function that abstracts away a lot of this boiler plate. How does this code look?

import React from 'react'
import nothisAll from 'nothis/nothisAll'

// 🔥 LIT: no this in sight!
class Counter extends React.Component {
  state = { count: 0 }

  constructor() {
    super()
    nothisAll(this)
  }

  increment({ setState }) {
    setState(({ count }) => ({ count: count + 1 }))
  }

  render({ increment, state }) {
    return (
      <div>
        <button onClick={increment}>{state.count}</button>
      </div>
    )
  }
}
Collapse
gmartigny profile image
Guillaume Martigny

Sorry, but I honestly laugh at

nothisAll(this)
Thread Thread
joelnet profile image
JavaScript Joel Author

The irony is not lost on me. I have opened an issue for this github.com/joelnet/nothis/issues/3

Thanks!

Thread Thread
joelnet profile image
JavaScript Joel Author

Your feedback has been invaluable in the creation of nothis-react. You can now create a Component like this:

import React from 'react'
import NoThis from 'nothis-react'

class Counter extends NoThis.Component {
  state = { count: 0 }

  increment({ setState }) {
    setState(({ count }) => ({ count: count + 1 }))
  }

  render({ increment, state: { count } }) {
    return (
      <div>
        <button onClick={increment}>{count}</button>
      </div>
    )
  }
}

Thanks again!

Thread Thread
entrptaher profile image
Md. Abu Taher 👨‍💻 • Edited on

It would make more sense with a more expressive usage like this, noMore(this), instead of noThisAll(this), noThatAll(that) and so on.

noMore(fun), noMore(function)...lol...

Thread Thread
joelnet profile image
JavaScript Joel Author

I am the worst at naming. This was actually my first opened issue on github github.com/joelnet/nothis/issues/1 lol

noMore(this) this makes sense when using this, but doesn't if it was noMore(obj), which may happen.

Collapse
belevatini profile image
Rocky Bronzino

I agree... Overcomplicating something just because you're not a fan of something is worse than learning to use it correctly. You can't assign a cat.speak function to a variable and expect it to be callable like a normal function. Methods implicitly get passed the object when called, so cat.speak() implicitly passes cat to speak. When you assign the speak function to a variable and call it directly it can't pass the cat anymore and will fail. The correct way to call from the assigned variable is speak.apply(cat) which will do same thing as cat.speak(). This is basic common sense when you understand how the language works.

Collapse
joelnet profile image
JavaScript Joel Author

For sure, experienced JavaScript programmers are aware of this. But a lot of JavaScript programmers out there are not. And A LOT of people are still get tripped up on this today.

for instance this code:

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

Would any reasonable person understand that if you use argument restructuring, the context to speak will be reassigned?

The best solution is to program without this. And when you program with a functional reactive style, you never have to use this, so you never have this problem.

Though you are not in control of 3rd party libraries and there are many 3rd party libraries which will force you to use this and the problems associated with it.

Thread Thread
nateous profile image
Nate

IMHO adding more libraries is worse for new developers. They won't know the difference between vanilla js functions and those of a library or framework.

Interesting concept but I'd prefer devs to learn the nuances of js.

Full disclosure: I'm a fan of vanilla js whenever possible.

Thread Thread
belevatini profile image
Rocky Bronzino

To me this is as obvious as x=y not being same thing as x="y" but I do understand the confusion to novice programmers, even "y" is confusing to some. I'm just suggesting that the language should not go out of it's way to cater to novice programmers.

Thread Thread
nateous profile image
Nate

Agreed, JavaScript is weird. But I love it! I also love C#. They're different languages with different works and benefits.

Thread Thread
joelnet profile image
JavaScript Joel Author

The best solution is to program without this at all. The next best solution is to fully understand this. When those fail, this just an alternative.

I agree that more people should favor vanilla JavaScript when possible.

Thread Thread
joelnet profile image
JavaScript Joel Author

To say nothis is for notice programmers, is to not understand all of the benefits that it can provide.

nothis will let you use argument destructuring. nothis will let you use arrow functions. nothis will name your context so you never have to write var self = this. nothis will let you write pure functions that output is computed solely on the input of other functions. nothis will let you use function composition.

Thread Thread
joelnet profile image
JavaScript Joel Author

This is why I love JavaScript. JavaScript can be what you imagine it to be. If you imagine a JavaScript without this you can have a JavaScript without this.

Thread Thread
zeddotes profile image
zeddotes

I'm happy you love JS, seriously. I think you have good intentions so as to provide the community with helpful utilities. I just wish that you would be more comfortable with this so you could see its use and benefits, especially leveraged with the fat arrow in particular.

If I could suggest something, take a look at apply and call Function methods; that should provide some clarity. Going beyond that, I'm curious to see what would happen if I did something like this:

noThisAll.call(this, this)
Thread Thread
joelnet profile image
JavaScript Joel Author

I think people have been trying to force OOP into JavaScript for a long time. I actually think classes were a mistake in JavaScript. But now that classes exist, people feel more and more comfortable with OO techniques.

JavaScript has Prototypal inheritance which is different than Class inheritance. But people coming from other languages start using JavaScript as if it were Class inheritance and that is where a lot of issues come from.

I feel like JavaScript is better suited for a functional reactive paradigm. Which doesn't require this at all.

The best solution is to code without this. Though sometimes you are stuck with this because of a 3rd library you are using.

If you look at the source code of nothis you will actually find that is exactly what it is doing behind the scenes. apply instead of call. github.com/joelnet/nothis/blob/mas...

So what you have suggested, is actually exactly how it works;)

Thread Thread
zeddotes profile image
zeddotes

There's no one best solution to every problem; what you're mentioning is subjective from case-to-case, dev-to-dev. You mention the use of functional reactive paradigm over OO, but then you're accessing this.event in your example; EventEmitter doesn't currently endorse that.

OO and Functional have their pros/cons and it's up to the infrastructure, architects, and developers to implement what works best as the solution to the problem, which is question to endless iterations of improvement over time.

We can sit here all day arguing about this, but I think it's clear where we both stand.

Ciao