Skip to content
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

Rule proposal: prefer-class-fields #314

Open
MrHen opened this issue Jun 3, 2019 · 10 comments
Open

Rule proposal: prefer-class-fields #314

MrHen opened this issue Jun 3, 2019 · 10 comments
Labels
💵 Funded on Issuehunt This issue has been funded on Issuehunt help wanted new rule

Comments

@MrHen
Copy link
Contributor

MrHen commented Jun 3, 2019

Issuehunt badges

There is a superior pattern for class field declarations that can declutter constructors (often making them totally unnecessary.) The feature is still considered experimental but it works out of the box with babel.

Fail:

class Foo {
  constructor() {
    this.foo = 'foo';
  }
}

Pass:

class Foo {
  foo = 'foo';
}

IssueHunt Summary

Backers (Total: $30.00)

Become a backer now!

Or submit a pull request to get the deposits!

Tips

@sindresorhus
Copy link
Owner

Sounds good, but I think we should wait until ESLint supports class fields.


Should it also handle:

class Foo {
  constructor() {
    this._foo = 'foo';
  }
}

to

class Foo {
  #foo = 'foo';
}

?

@sindresorhus sindresorhus changed the title Rule Proposal: Prefer field declarations Rule Proposal: Prefer class fields Jun 10, 2019
@MrHen
Copy link
Contributor Author

MrHen commented Jun 10, 2019

I think a rule for private fields would be awesome, yeah. I don't think we can realistically auto-fix those, however, because people abuse _foo access too regularly and it would very quickly break code.

@sindresorhus
Copy link
Owner

So you think private fields should be a separate rule?


I don't think we can realistically auto-fix those, however, because people abuse _foo access too regularly and it would very quickly break code.

👍

@MrHen
Copy link
Contributor Author

MrHen commented Jun 10, 2019

Yeah. As a general principle, I prefer rules to be have the smallest reasonable scope.

In this case, I can also see why a team might want to convert to class fields because of the fixer but not want to enable the private fields rule right away because they'd have to move a bunch of code around.

@sindresorhus sindresorhus changed the title Rule Proposal: Prefer class fields Rule proposal: Prefer class fields Sep 5, 2019
@sindresorhus
Copy link
Owner

Issue for private class fields: #979

@sindresorhus
Copy link
Owner

Does ESLint support class fields yet?

@sindresorhus sindresorhus changed the title Rule proposal: Prefer class fields Rule proposal: prefer-class-fields Jan 1, 2021
@fregante
Copy link
Collaborator

fregante commented Dec 17, 2021

Does ESLint support class fields yet?

It does now

This rule would be pretty useful on Error constructors like:

class MyError extends Error {
  constructor(message: string) {
    super(message);
    this.name = "MyError";
  }
}

👇

class MyError extends Error {
  name = "MyError"
}

@sindresorhus
Copy link
Owner

This is accepted.

@jimmywarting

This comment was marked as spam.

Copy link

issuehunt-oss bot commented Feb 29, 2024

@fregante has funded $30.00 to this issue.


@issuehunt-oss issuehunt-oss bot added the 💵 Funded on Issuehunt This issue has been funded on Issuehunt label Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💵 Funded on Issuehunt This issue has been funded on Issuehunt help wanted new rule
Projects
None yet
Development

No branches or pull requests

4 participants