sort-comp.md

Enforce component methods order (react/sort-comp)

When creating React components it is more convenient to always follow the same organisation for method order to help you easily find lifecyle methods, event handlers, etc.

Fixable: This rule is automatically fixable using the sort-comp transform in react-codemod.

Rule Details

The default configuration ensures that the following order must be followed:

1. static methods and properties
2. lifecycle methods: displayName, propTypes, contextTypes, childContextTypes, mixins, statics,defaultProps, constructor, getDefaultProps, getInitialState, state, getChildContext, componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentWillUpdate, componentDidUpdate, componentWillUnmount (in this order).
3. custom methods
4. render method

The following patterns are considered warnings:

var Hello = createReactClass({
  render: function() {
    return <div>Hello</div>;
  },
  displayName : 'Hello'
});

The following patterns are not considered warnings:

var Hello = createReactClass({
  displayName : 'Hello',
  render: function() {
    return <div>Hello</div>;
  }
});

Rule Options

This rule can take one argument to customize the components organisation.

...
"react/sort-comp": [<enabled>, { order: <order>, groups: <groups> }]
...

• enabled: for enabling the rule. 0=off, 1=warn, 2=error. Defaults to 0.
• order: optional array of methods to validate.
• groups: optional object of methods groups.

The default configuration is:

{
  order: [
    'static-methods',
    'lifecycle',
    'everything-else',
    'render'
  ],
  groups: {
    lifecycle: [
      'displayName',
      'propTypes',
      'contextTypes',
      'childContextTypes',
      'mixins',
      'statics',
      'defaultProps',
      'constructor',
      'getDefaultProps',
      'getInitialState',
      'state',
      'getChildContext',
      'componentWillMount',
      'componentDidMount',
      'componentWillReceiveProps',
      'shouldComponentUpdate',
      'componentWillUpdate',
      'componentDidUpdate',
      'componentWillUnmount'
    ]
  }
}

• static-methods is a special keyword that refers to static class methods.
• lifecycle is referring to the lifecycle group defined in groups.
• everything-else is a special group that match all the methods that do not match any of the other groups.
• render is referring to the render method.
• type-annotations. This group is not specified by default, but can be used to enforce flow annotations positioning.
• getters This group is not specified by default, but can be used to enforce class getters positioning.
• setters This group is not specified by default, but can be used to enforce class setters positioning.
• instance-variables This group is not specified by default, but can be used to enforce all other instance variables positioning.
• instance-methods This group is not specified by default, but can be used to enforce all other instance methods positioning.

You can override this configuration to match your needs.

For example, if you want to place your event handlers (onClick, onSubmit, etc.) before render but the other methods after it:

"react/sort-comp": [1, {
  order: [
    'static-methods',
    'lifecycle',
    '/^on.+$/',
    'render',
    'everything-else'
  ]
}]

With the above configuration, the following patterns are considered warnings:

var Hello = createReactClass({
  render: function() {
    return <div>Hello</div>;
  },
  onClick: function() {}
});

With the above configuration, the following patterns are not considered warnings:

var Hello = createReactClass({
  onClick: function() {},
  render: function() {
    return <div>Hello</div>;
  }
});

If you want to split your render method into smaller ones and keep them just before render:

"react/sort-comp": [1, {
  order: [
    'static-methods',
    'lifecycle',
    'everything-else',
    'rendering',
  ],
  groups: {
    rendering: [
      '/^render.+$/',
      'render'
    ]
  }
}]

With the above configuration, the following patterns are considered warnings:

var Hello = createReactClass({
  renderButton: function() {},
  onClick: function() {},
  render: function() {
    return <div>Hello</div>;
  }
});

With the above configuration, the following patterns are not considered warnings:

var Hello = createReactClass({
  onClick: function() {},
  renderButton: function() {},
  render: function() {
    return <div>Hello</div>;
  }
});

If you want to flow annotations to be at the top:

"react/sort-comp": [1, {
  order: [
    'type-annotations',
    'static-methods',
    'lifecycle',
    'everything-else',
    'render',
  ],
}]

With the above configuration, the following patterns are considered warnings:

class Hello extends React.Component<any, Props, void> {
  onClick() { this._someElem = true; }
  props: Props;
  _someElem: bool;
  render() {
    return <div>Hello</div>;
  }
}

With the above configuration, the following patterns are not considered warnings:

type Props = {};
class Hello extends React.Component<any, Props, void> {
  props: Props;
  _someElem: bool;
  onClick() { this._someElem = true; }
  render() {
    return <div>Hello</div>;
  }
}

When Not To Use It

This rule is a formatting preference and not following it won't negatively affect the quality of your code. If components organisation isn't a part of your coding standards, then you can leave this rule off.