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
Comments
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 :) |
More comments on this on commit d657ea5 Two issues here:
|
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:
This could be another rule, complementary to this one, that validates/enforces the right type of method, for example 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. ES5order: [
'lifecycle',
'everything-else',
'render'
],
groups: {
lifecycle: [
'displayName',
'propTypes',
'contextTypes',
'childContextTypes',
'mixins',
'statics',
'getDefaultProps',
'getInitialState',
// Rest stays the same.
]
} ES6 - external class propertiesorder: [
'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 methodsorder: [
'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 propertiesorder: [
'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 |
Is this kind of behaviour possible to specify, all class properties/property initialisers allowed to go at the top? |
any update to support the ES7 static property? |
I have not started working on it yet. I'll try to look at it this week. |
@yannickcr @tleunen |
@josephfinlayson Thanks! I'll have a look. |
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! |
@davezuko Sorry for the delay, I'll try to work on this next week. |
Any updates on this? This rule becomes unusable if I have flow :( |
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 ;) ) |
please do not forget about static function/props |
Hey, when are you expecting to publish this fix? Btw for all interested, for the meanwhile I added this to my
After you change it will be something like this:
|
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
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
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
Add static method support to sort-comp (fixes #128)
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
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
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
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
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
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
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
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.
The text was updated successfully, but these errors were encountered: