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.

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>
    )
  }
}

Don't worry, you will. Everyone does ;)

Check out this example:

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

cat.speak() //=> "meow"

const speak = cat.speak;
speak(); //=> undefined

You will also frequently run into problems with this when working with React.

// INVALID REACT CODE
class Counter extends React.Component {
  increment() {
    this.setState(s => ({ count: s.count + 1 }))
  }

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

I have a few other examples on the github page github.com/joelnet/nothis

It's mostly people incorrectly using the language when they say this has problems. It's pretty clearly defined as to what it does and where it's used. I use it all over my code with no issues at all.

You seem to be suffering from the Dunning–Kruger effect. Just because you do not have a problem does not mean that others do not. A simple search on stack overflow or google will show this is a problem for many JavaScript developers.

Take a look at this code:

const logSpeak = animal => console.log(animal.speak())
//=> "meow"
const logSpeak = ({ speak }) => console.log(speak())
// undefined

By simply converting a function to use argument destructuring, you will cause the function to fail. It is not reasonable to assume this.

When you bind or apply or use arrow functions to use the parent scope, these are all things that had to be learned. Not everyone is at that level. Do you remember WHY you had to learn those things?

I do not know a single JavaScript developer that hasn't written console.log(this) to figure out WTF this is. And if you tell me you haven't, I'll call you a liar ;)

Cheers!

For experienced programmers, this isn't much of an issue. We are aware of the problems and how to correctly use it.

Though for the rest of the JavaScript programmers that have yet to achieve that level of experience, they will surely stumble on this. (as stack overflow questions suggest).

Bug with this are guaranteed. I have not seen a single JavaScript developer that hasn't written console.log(this) just to try and figure out WHAT IS THIS.

The best solution is to not program with this at all. Use a functional reactive style.

The library is just days old and needs a lot of work for sure. But take a look at this code (nothis v1.2.1). I would say this is more readable because of nothis.

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>
    )
  }
}

I think once we've gained an understanding of this we forgot the journey it took to get there. We hold onto it as a badge of achievement. It's an accomplishment because it was so difficult. And now that we finally get it, why are we getting rid of it? After I spent all that time to finally learn it? Even knowing full well that we will run into issues with it again in our future.

My journey with this has ended. I'm not gonna keep it around for nostalgia.

My article How I rediscovered my love for JavaScript after throwing 90% of it in the trash might explain more of how I feel and why I am eliminating this.

Sometimes you do not have control over the code you are using. An example of this would be 3rd party libraries.

I am forced to use this here because that is how the library is written.

events.on('button.*', function() {
  console.log('event:', this.event)
})

this prevents me from writing code like this

events.on('button.*', () => console.log('event:', this.event))
//=> Error

or like this:

events.on('button.*', ({ event }) => console.log('event:', event))
//=> Error

But with nothis I can write my function like this:

events.on('button.*', nothis(({ event }) => console.log('event:', event)))

Very well thought out reply. And I agree with quite a lot of what you have written.

I prefer to code in a functional reactive style. This style naturally doesn't contain this. So it's rarely a problem. It's the style I preach and I find JavaScript is perfect for it. The problems above would never appear. The problems I have appear when I use 3rd party libraries that force me to use this. Now instead of writing small algebras, I have to revert to writing classic functions with return and this.

I also wanted to demonstrate many different waysnothis could be used. Though, as you have already pointed out, the best solution is to not use this at all!

For many people this isn't as easy. It takes time to wrap your head around a classless codebase. Pure functions and immutability.

This is the reason why I am asking the question Do we have to use this?

As you have correctly pointed out, nothing comes without a cost. A library has a cost (even small ones like left-pad). Any abstraction is a cost. Even design patterns have a cost. So if someone thinks anything comes without a cost, is to not full understand the thing. nothis included.

So you have to weigh the pros and cons of nothis when considering it for your project. This means that (like anything with a cost) is not for every project.

PROS:

• Confusion around what is this is gone. (no more console.log(this))
• Functions attached to the context are bound so code like <Button onClick={ctx.handler} /> will work.
• The context argument can be destructured.
• Nested this contexts no longer require var self = this.
• You no longer have to learn why you need code like this.method = this.method.bind(this) in your constructor. or why this works {() => func()} but this doesn't {func}. Or why your code works here, but stops working in a setTimeout.

CONS:

• nothis is an abstraction and therefore must be understood by all developers on the team.
• overhead of an added library.
• overhead of having to wrap functions in nothis.

For me, the pros outweigh the cons and can be used today in any project and even projects that do not have any transpiling like babel.

Your abstraction might work well for developers like you, who are well experienced with nitty-gritty details of this. A junior developer like me would find the nothisAll too magical!

I would disagree with this point though. I think teaching a new developer the ins and out and all the gotchas of this is far more complex than teaching them about nothis. It is an abstraction, but I don't see anything overly complex about receiving the sender as the first argument. It's follows a similar pattern to C# event handlers:

void button_OnClick(object sender, EventArgs e) { }

But if you ask me whether I would let my kids use it? My answer would be no.

It would be best to first teach your kids to not program with this. Because that is the true solution.

Yes! The best article I have read on this is Why Programmers Need Limits.

When you introduce the constraint of not using this, you'll find yourself programming functionally, which I love.

Functional Reactive Programming FTW!

Cheers!

The dependency and bundle cost is absolutely a cost that should be weighed when considering all packages. More people should think this way.

NULL is also an integral part of JavaScript. NULL has now been labeled the Billion dollar mistake. How much will THIS cost us?

There are pro's and con's to everything in this world. So for me to say nothis doesn't come with a cost would be a lie. There is a cost for sure. And you have to weigh the pros and cons before considering it for a project. This should be true with every library, or even design pattern.

Have a look at this:

Does that look complicated?