Skip to main content
interlace
Plugin: react-featuresRules

sort-comp

sort-comp rule

sort-comp rule

Enforce component method ordering in React class components. This rule is part of eslint-plugin-react-features.

Quick Summary

AspectDetails
SeverityWarning (organization)
Auto-Fix❌ No (requires reordering)
CategoryReact
ESLint MCP✅ Optimized for ESLint MCP integration
Best ForReact class components with consistent style

Rule Details

Enforces a consistent ordering of methods within React class components, making code more predictable and easier to navigate.

Why This Matters

IssueImpactSolution
🔄 Inconsistent structureHard to find methodsStandardized ordering
🐛 Review difficultyDifferent patterns across teamConsistent conventions
🔍 OnboardingNew devs struggle to navigatePredictable structure

Default Order

  1. static-variables - Static class properties
  2. static-methods - Static methods
  3. instance-variables - Instance properties
  4. lifecycle - React lifecycle methods
  5. everything-else - Custom methods
  6. render - The render method (always last)

The lifecycle group holds the constructor and React's lifecycle methods (componentDidMount, shouldComponentUpdate, componentDidUpdate, componentWillUnmount, …); their order among themselves is not checked. Member names are read in every spelling (['render']()). The class must extend React's Component or PureComponent, by binding, declared or as a class expression.

Examples

❌ Incorrect

class UserProfile extends React.Component {
  // BAD: render before lifecycle
  render() {
    return <div>{this.state.name}</div>;
  }
  
  // BAD: lifecycle after render
  componentDidMount() {
    this.fetchUser();
  }
  
  // BAD: constructor not first
  constructor(props) {
    super(props);
    this.state = { name: '' };
  }
  
  // BAD: static after instance methods
  static propTypes = {
    userId: PropTypes.string.isRequired
  };
}

✅ Correct

class UserProfile extends React.Component {
  static propTypes = {
    userId: PropTypes.string.isRequired,
  };

  state = { name: '' };

  constructor(props) {
    super(props);
  }

  componentDidMount() {
    this.fetchUser();
  }

  fetchUser() {}

  render() {
    return <div>{this.state.name}</div>;
  }
}

Options

OptionTypeDefaultDescription
orderstring[]See default orderArray of group names in order

Configuration with Options

{
  rules: {
    'react-features/sort-comp': ['warn', {
      order: [
        'static-variables',
        'static-methods',
        'lifecycle',
        'instance-variables',
        'everything-else',
        'render'
      ]
    }]
  }
}

Configuration Examples

Basic Usage

{
  rules: {
    'react-features/sort-comp': 'warn'
  }
}

Further Reading

Known False Negatives

  • Lifecycle methods are not ordered among themselves; only the groups are.
  • getDerivedStateFromProps is a static method, so it sorts with static-methods.

Use this rule

npm install -D oxlint-plugin-react-features
.oxlintrc.json
{  "jsPlugins": ["oxlint-plugin-react-features"],  "rules": {    "react-features/sort-comp": "error"  }}
vite.config.ts
import { defineConfig } from 'vite-plus';export default defineConfig({  lint: {    jsPlugins: ['oxlint-plugin-react-features'],    rules: {      'react-features/sort-comp': 'error',    },  },});

oxlint-plugin-react-features re-exports eslint-plugin-react-features/oxlint: the same rules under the same IDs, and no ESLint install. Why oxlint.

Did this rule catch something? Star the repo to get new CWE coverage as we ship it — or follow the AI-code-security benchmarks behind these rules.