Add instance-properties group to sort-comp. Issue #599.

[le0nik]

Relevant issue: #599

It's a common convention to have instance properties on top(right below the static properties/methods), like this:

class Hello extends React.Component {
  static displayName = 'Hello';

  count = 0;

  componentDidMount() {
    // ...
  }

  handleClick = () => {
    this.count += 1;
    // ...
  }

  render() {
    // ...
  }
}

Right now sort-comp rule doesn't allow that and wants count to be below componentDidMount, unless you specify it by name in the configuration.

This PR's aim is to allow placing instance properties separately.

The default configuration is not changed.

[ljharb]

Allowing it to be configurable is excellent. However, changing the default order makes it a breaking change. Should this preserve the default order, and be semver-minor, and change the default later?

[le0nik]

@ljharb I've reverted the default order. My initial way of thinking was that this change could be part of 6.0.0, considering that it's in alpha now.

[ljharb]

That's a fair point. @yannickcr should weigh in on that.

[yannickcr]

Since 6.0.0 is imminent we could do this, but I don't know if it is a good thing to force instance properties on top in the default configuration.

What is the most common order used by React users here?

[ljharb]

Instance properties are still stage 1, so we don't use them yet at Airbnb. However, since instance properties run almost as if they were in the constructor, i think they absolutely should all be placed just like the constructor - at the top.

[kylpo]

This has become a common pattern for the react community, and one that I would certainly like to enforce in my projects. Mind taking another look at this and weighing in on why it is not accepted? (other than the conflicts to be resolved now)

[lencioni]

It would be great to get a rebase of this.

[lencioni]

It looks like this documentation needs to be updated, since the default order has not been modified yet.

It would be nice to open a PR that updates the default and documentation that we could bring in as part of v7.0.0.

[klimashkin]

Public Class Fields are on stage 2 already, why it still hasn't been merged into 7.x?...

[ljharb]

@klimashkin this needs reviews from more collabs first, and it needs a rebase.

Separately, stage 3 is the time when it's safe to start using a feature, so that's when it will become critical to be supported here.

[yannickcr]

Default configuration should not be updated in the documentation (see @lencioni comment) and a rebase is needed.

[noahbenham]

Class fields is now a stage 3 proposal. Happy to contribute if this needs someone else to take it on.

[ljharb]

Unfortunately @le0nik deleted their fork, so this PR can never land.