Use this for filter/action definitions

[jnicklas]

I know everyone hates this in JavaScript, so I'm very much doubting whether this is a good idea. But I thought I'd point it out in a discussion, since IMO it does have some merit. The proposal is to change this:

const Link = createInteractor<HTMLLinkElement>('link')
  .actions({
    click: ({ perform }) => perform((element) => { element.click(); }),
  })

To this:

const Link = createInteractor<HTMLLinkElement>('link')
  .actions({
    click() {
      return this.perform((element) => { element.click(); });
    }
  })

Before you say eugh, hear me out! Why might we want to do this?

Prior art

It is natural, in a way, because click is a method and this inside of a method refers to the object that the method operates on. This is natural, and familiar from all types of methods in JS land.

Arity

Another argument for this is that it makes passing arguments to actions more natural:

From this:

const Field = createInteractor<HTMInputElement>('field')
  .actions({
    fillIn: ({ perform }, value: string) => perform((element) => { element.value = value }),
  })

Field().fillIn('someValue');

To this:

const Field = createInteractor<HTMInputElement>('field')
  .actions({
    fillIn(value: string) {
      return this.perform((element) => { element.value = value });
    }
  })

Field().fillIn('someValue');

Note that in the first example, the action definition takes two arguments, but when the action gets called it only takes one argument. This is weird. Who provides the other argument? In the second example, there is a natural link between the definition and the call site.

Filter delegation

Finally another argument is that we want to eventually allow some type of delegation for filters, this would require us to get a hold of some reference to the interactor. Since we pass the interactor as the first argument for actions, that's probably also what we'll want to do with filters. But most filters will not use that argument, so then we'll need to ignore this argument. Using this there is an easy, straightforward path to making filters and actions work the same way. There is no such option for any other API as far as I can see.

[taras]

this is more obvious in my opinion - but I'm also not a this hater.

[dagda1]

I am going to add some balance :) by saying that I AM a this hater :).

this has always been duplicitous in javascript and the source of much weirdness and bugs. You end up with scoping and closure problems and it is not always clear what this is due to arrow functions and if you ever have to do this const that = this then all hope is lost.

this can be hijacked with apply, call and bind.

this is a messy business that is best avoided in my opinion.

[jnicklas]

this has always been duplicitous in javascript and the source of much weirdness and bugs. You end up with scoping and closure problems and it is not always clear what this is due to arrow functions and if you ever have to do this const that = this then all hope is lost.

Agree on some of this. const this = that is definitely a horrible anti-pattern. Arrow functions do alleviate some of this pain, and I feel that this is not as bad anymore as it once was. That being said, I very much agree that reasoning about this can be difficult.

this can be hijacked with apply, call and bind.

While this is true, being able to change this via apply is why we would be doing this in the first place, so it's not really an argument against in this case ;)

this is a messy business that is best avoided in my opinion.

I too am apprehensive about this. That being said, I am not opposed to it on principle alone and I do believe that the arguments I made above make a pretty compelling case for it in this specific instance.

It's also worth mentioning that TypeScript can alleviate some of the pain of this, since it can type it properly for us.

[cowboyd]

The biggest disconnect that I see is that then you'll be forced to use the function () {} syntax. I'm not opposed too terribly to using this, but given that the prevailing forces expect fat arrow functions to have a happy path, this seems like a tough sell to the wider community.

I wish there was a way to make it optional. That way we could try it out.

[jnicklas]

The property method syntax does not bind this, so can be used. Both of these will work:

const Field = createInteractor<HTMInputElement>('field')
  .actions({
    fillIn: function(value: string) {
      return this.perform((element) => { element.value = value });
    }
  })

const Field = createInteractor<HTMInputElement>('field')
  .actions({
    fillIn(value: string) {
      return this.perform((element) => { element.value = value });
    }
  })

This will not:

const Field = createInteractor<HTMInputElement>('field')
  .actions({
    fillIn: (value: string) => {
      return this.perform((element) => { element.value = value });
    }
  })