New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for ESnext Class Feature #1521

Open
cheshireoctopus opened this Issue Aug 14, 2017 · 13 comments

Comments

Projects
None yet
3 participants
@cheshireoctopus
Copy link

cheshireoctopus commented Aug 14, 2017

Hello,

Curious if support for ESnext classes is can be expected now that the feature has been moved from stage-2 to stage-3.

If not, at what point (if any) will this feature be included?

Currently using the work around detailed in #589.

Thank you

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Aug 14, 2017

As soon as eslint core supports it - sadly they aren't likely to do so until stage 4.

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Aug 14, 2017

(Separately; we'd very much want a rule to prohibit arrow functions in class properties; these should always be constructor-bound instance methods)

@cheshireoctopus

This comment has been minimized.

Copy link
Author

cheshireoctopus commented Aug 14, 2017

As soon as eslint core supports it - sadly they aren't likely to do so until stage 4.

Good to know.

Separately; we'd very much want a rule to prohibit arrow functions in class properties; these should always be constructor-bound instance methods

Interesting - why does the team feel this way?

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Aug 14, 2017

Let's say you do this:

class Foo extends React.Component {
  foo = () => { console.log(this.props.bar); }

  render() {
    return <div onClick={this.foo} />
  }
}

If you create N Foo elements, you're creating N "foo" functions. The JS engine can optimize functions when the same function is called repeatedly - in this case, for a single click on all the <Foo />s, every function is called once.

However, if you do this:

class Foo extends React.Component {
  constructor(..args) {
    super(...args);
    this.foo = this.foo.bind(this);
  }

  foo() { console.log(this.props.bar); }

  render() {
    return <div onClick={this.foo} />
  }
}

then for N Foo elements, you still get only one "foo" method - the thing you get N times is the simple bind-proxy to it. That means that when all the <Foo />s get clicked, you're still calling the bind-proxy N times - which the engine may or may not optimize - but you're calling the same Foo.prototype.foo N times, which means the engine can optimize it.

Additionally, this means Foo.prototype.foo can be borrowed and .called (which is highly idiomatic for JS), and it can be more easily mocked out in tests, or unit-tested directly - not reasons to pick a pattern, but nice bonuses.

Once decorators land, this would be an ergonomic possibility:

class Foo extends React.Component {
  @autobound
  foo() { console.log(this.props.bar); }

  render() {
    return <div onClick={this.foo} />
  }
}
@cheshireoctopus

This comment has been minimized.

Copy link
Author

cheshireoctopus commented Aug 14, 2017

@ljharb - thank you for the detailed explanation +1

luisherranz referenced this issue in worona/saturn-app-theme-worona Sep 4, 2017

@danm

This comment has been minimized.

Copy link

danm commented Aug 14, 2018

@ljharb do you still feel the same? Is the detriment bad enough to avoid public class fields? They are just so ultra convenient to write. But still in stage 3 :(

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Aug 14, 2018

@danm a) eslint won't parse anything that's not stage 4, b) class fields must never have arrow functions, so we wouldn't permit them until we had a rule that prevented functions from going in class fields.

@danm

This comment has been minimized.

Copy link

danm commented Aug 19, 2018

@ljharb Flow docs advise to use class fields with arrow functions. I wonder how these are compiled down? I know flow technically is a different syntax, but does this teach bad practices... or just the mindset this is different? https://flow.org/en/docs/react/events/

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Aug 19, 2018

Flow is type annotations; the language syntax doesn’t differ. There’s lots of docs casually using arrow functions in class fields; that doesn’t mean they’re correct. It’s a new feature, so the knowledge of why to avoid them hasn’t spread yet.

@danm

This comment has been minimized.

Copy link

danm commented Aug 19, 2018

are there any airbnb style guides for flow?

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Aug 19, 2018

No, we don’t use flow. However I’m not sure how it would differ much; Flow is simple type annotations on top of existing JS syntax.

@danm

This comment has been minimized.

Copy link

danm commented Aug 19, 2018

main thing at the moment is linting facebook/flow#5874

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Aug 19, 2018

Looks like Flow has a bug to fix then; that pattern should work with or without class fields.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment