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

sort-comp: statics out of lifecycle? #128

Closed
tleunen opened this issue Jun 23, 2015 · 14 comments · Fixed by #429
Closed

sort-comp: statics out of lifecycle? #128

tleunen opened this issue Jun 23, 2015 · 14 comments · Fixed by #429

Comments

@tleunen
Copy link

tleunen commented Jun 23, 2015

https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/sort-comp.md

I think it would make sense to put the statics out of the lifecycle and put them in the order structure. Usually, you put the static variables at the top of your class, then your constructor and then the lifecycle functions.

@tleunen
Copy link
Author

tleunen commented Jun 23, 2015

Ok just read the comment from #100. It seems the group "statics" from the rule is not what I think it was.

I keep this thing open, since it could be a nice enhancement. Currently, eslint tells me to put propTypes after my constructor, but it doesn't make sense for me :)

@yannickcr
Copy link
Member

More comments on this on commit d657ea5

Two issues here:

@mathieumg
Copy link
Contributor

I'll continue the discussion from d657ea5 in here for better visibility, I doubt many people will read that one and/or search for it.

In reply to d657ea5#commitcomment-11816207:

In second case the method type can be static, get, static get or none. In third case the property type can be static or none. The static type does not seems to be mandatory.

This could be another rule, complementary to this one, that validates/enforces the right type of method, for example defaultProps should always be static while state should never be.

Back to the topic at hand, however. I created a list for what the config "should look like" for the different syntaxes, I imagine we only need to find a way that works with as many as possible/the most common ones.

ES5
order: [
  'lifecycle',
  'everything-else',
  'render'
],
groups: {
  lifecycle: [
     'displayName',
     'propTypes',
     'contextTypes',
     'childContextTypes',
     'mixins',
     'statics',
     'getDefaultProps',
     'getInitialState',
     // Rest stays the same.
  ]
}
ES6 - external class properties
order: [
  'constructor',
  'lifecycle',
  'es-getters-setters', // Special variable, each get is paired with the same-name set if existing. 'es-getters' and 'es-setters' would be used to have them grouped by get/set instead. I imagine a variant with all of these with '-static' appended could be use to target only the static ones. Otherwise, the static ones could be placed at the beginning by default. 
  'everything-else',
  'render'
],
groups: {
  lifecycle: [
     'getDefaultProps',
     'getInitialState',
     // Rest stays the same.
  ]
}

In this case, the "static" properties get set after the class definition, is it our duty to validate their order, there?

ES6 - class methods
order: [
  'constructor',
  'lifecycle',
  'es-getters-setters', // Technically this would exclude those that are part of 'lifecycle'  but do we want that? Starting to get heavy both configuration and implementation wise.
  'everything-else',
  'render'
],
groups: {
  lifecycle: [
     'displayName',
     'propTypes',
     'contextTypes',
     'childContextTypes',
     'mixins',
     'statics',
     'defaultProps',
     'state',
     'getDefaultProps',
     'getInitialState',
     // Rest stays the same.
  ]
}
ES7 - class properties
order: [
  'lifecycle',
  'es-getters-setters', // Technically this would exclude those that are part of 'lifecycle'.
  'everything-else',
  'render'
],
groups: {
  lifecycle: [
     'displayName',
     'propTypes',
     'contextTypes',
     'childContextTypes',
     'mixins',
     'statics',
     'defaultProps',
     'state',
     'constructor',
     'getDefaultProps',
     'getInitialState',
     // Rest stays the same.
  ]
}

I guess I'm just brainstorming "out loud". 😜 Most of the time, the difficulty comes from the fact that many syntax styles can be combined/used at once, for example nothing prevents me from using a class definition with a standard getDefaultProps method and a state class property.

@josephfinlayson
Copy link

class ImageCarousel extends React.Component {
    a = "b"
   constructor(){ 
   }
   render(){}
}

Is this kind of behaviour possible to specify, all class properties/property initialisers allowed to go at the top?

@tleunen
Copy link
Author

tleunen commented Aug 9, 2015

any update to support the ES7 static property?

@yannickcr
Copy link
Member

I have not started working on it yet. I'll try to look at it this week.

@josephfinlayson
Copy link

@yannickcr @tleunen
We've done it at Hubrick, have a look and see if it can be ported
https://github.com/hubrick/eslint-plugin-classes/blob/master/tests/rules/order.js

@yannickcr
Copy link
Member

@josephfinlayson Thanks! I'll have a look.

@dvdzkwsk
Copy link

Any progress on this? Just curious because my team's been running into this issue and it would be nice to have support directly from eslint-plugin-react. This plugin is awesome; having this would just seal the deal.

Thanks!

@yannickcr
Copy link
Member

@davezuko Sorry for the delay, I'll try to work on this next week.

@satya164
Copy link

Any updates on this? This rule becomes unusable if I have flow :(

@yannickcr
Copy link
Member

Sorry, I was busy on other things and totally forgot this issue. So no update on this for now. But I'll try to do something about this (I also accept PR ;) )

@CosticaPuntaru
Copy link

please do not forget about static function/props

@unimonkiez
Copy link

Hey, when are you expecting to publish this fix?

Btw for all interested, for the meanwhile I added this to my .eslintrc to support both sorting of react's classes and my es6 classes using this plugin -

"sort-class-members/sort-class-members": [2, {
  "order": [
    "[static-properties]",
    "[static-methods]",
    "[properties]",
    "[conventional-private-properties]",
    "constructor",
    "[lifecycle]",
    "render",
    "/^render.+$/",
    "[everything-else]"
  ],
  "groups": {
    "lifecycle": [
      "displayName",
      "propTypes",
      "contextTypes",
      "childContextTypes",
      "mixins",
      "statics",
      "defaultProps",
      "constructor",
      "getDefaultProps",
      "state",
      "getInitialState",
      "getChildContext",
      "componentWillMount",
      "componentDidMount",
      "componentWillReceiveProps",
      "shouldComponentUpdate",
      "componentWillUpdate",
      "componentDidUpdate",
      "componentWillUnmount"
    ]
  }
}],
"react/sort-comp": 0

After you change it will be something like this:

"sort-class-members/sort-class-members": [2, {
  "order": [
    "[static-properties]",
    "[static-methods]",
    "[properties]",
    "[conventional-private-properties]",
    "constructor"
    "[everything-else]"
  ]
}],
"react/sort-comp": [2, {
  order: [
    'constructor',
    'lifecycle',
    'render',
    '/^render.+$/',
    'everything-else'
  ]
}]

lencioni added a commit to lencioni/javascript that referenced this issue Feb 4, 2016
I think it makes more sense to put static methods above the constructor
in classes. I would like to update the ESLint configuration to match
this, but it looks like the react/sort-comp rule does not support it
quite yet.

  jsx-eslint/eslint-plugin-react#128
lencioni added a commit to lencioni/eslint-plugin-react that referenced this issue Feb 5, 2016
A number of people have said that they think it makes sense for static
class methods to appear at the very top of classes. This commit allows
this to be configured by adding the `static-methods` keyword to the
sort-comp rule.

Fixes jsx-eslint#128
lencioni added a commit to lencioni/eslint-plugin-react that referenced this issue Feb 5, 2016
A number of people have said that they think it makes sense for static
class methods to appear at the very top of classes. This commit allows
this to be configured by adding the `static-methods` keyword to the
sort-comp rule.

Fixes jsx-eslint#128
@yannickcr yannickcr mentioned this issue Feb 9, 2016
7 tasks
yannickcr added a commit that referenced this issue Feb 14, 2016
Add static method support to sort-comp (fixes #128)
gilbox pushed a commit to gilbox/javascript that referenced this issue Mar 21, 2016
I think it makes more sense to put static methods above the constructor
in classes. I would like to update the ESLint configuration to match
this, but it looks like the react/sort-comp rule does not support it
quite yet.

  jsx-eslint/eslint-plugin-react#128
jaylaw81 pushed a commit to appirio-digital/ads-best-practices that referenced this issue Sep 19, 2017
I think it makes more sense to put static methods above the constructor
in classes. I would like to update the ESLint configuration to match
this, but it looks like the react/sort-comp rule does not support it
quite yet.

  jsx-eslint/eslint-plugin-react#128
sensiblegame added a commit to sensiblegame/React-BNB that referenced this issue Oct 23, 2017
I think it makes more sense to put static methods above the constructor
in classes. I would like to update the ESLint configuration to match
this, but it looks like the react/sort-comp rule does not support it
quite yet.

  jsx-eslint/eslint-plugin-react#128
passionSeven added a commit to passionSeven/javascript that referenced this issue Jan 27, 2023
I think it makes more sense to put static methods above the constructor
in classes. I would like to update the ESLint configuration to match
this, but it looks like the react/sort-comp rule does not support it
quite yet.

  jsx-eslint/eslint-plugin-react#128
Binary-Ninja-007 pushed a commit to Binary-Ninja-007/JavaScript_Style_Guide that referenced this issue Aug 13, 2023
I think it makes more sense to put static methods above the constructor
in classes. I would like to update the ESLint configuration to match
this, but it looks like the react/sort-comp rule does not support it
quite yet.

  jsx-eslint/eslint-plugin-react#128
harry908nilson pushed a commit to marcolane/Javascriipt that referenced this issue Sep 1, 2023
I think it makes more sense to put static methods above the constructor
in classes. I would like to update the ESLint configuration to match
this, but it looks like the react/sort-comp rule does not support it
quite yet.

  jsx-eslint/eslint-plugin-react#128
noakosar515 pushed a commit to noakosar515/JavaScript that referenced this issue Sep 14, 2023
I think it makes more sense to put static methods above the constructor
in classes. I would like to update the ESLint configuration to match
this, but it looks like the react/sort-comp rule does not support it
quite yet.

  jsx-eslint/eslint-plugin-react#128
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

8 participants