eslint-plugin-react-component-name

Motivation

• Autofix based on variable name.
• Better error traces in console for debug.
• Support for any High-order components and compositions (e.g. MobX's observer or nesting like memo(forwardRef(() => <div />)))
• Universal solution based solely on ESLint.

Installation

Install the package using npm or yarn:

npm install eslint-plugin-react-component-name --save-dev

Usage

Add the plugin to your .eslintrc configuration:

{
  "plugins": ["react-component-name"],
  "extends": ["plugin:react-component-name/recommended"]
}

You can change the default rule setting (memo, forwardRef) by adding targets option in the rules section.

Also, if you are using "prefer-arrow-callback" rule, it is required to add allowNamedFunctions option to it.

{
  "plugins": ["react-component-name"],
  "rules": {
    "prefer-arrow-callback": ["error", { "allowNamedFunctions": true }],

    "react-component-name/react-component-name": [
      "error",
      {
        "targets": ["memo", "forwardRef", "observer"]
      }
    ]
  }
}

Examples

Wrong Code

const MyComponent = memo(() => {
  return <div>Hello</div>;
});

const MyRef = forwardRef((props, ref) => {
  return <input ref={ref} {...props} />;
});

Fixed Code

const MyComponent = memo(function MyComponent() {
  return <div>Hello</div>;
});

const MyRef = forwardRef(function MyRef(props, ref) {
  return <input ref={ref} {...props} />;
});

Motivation

When developing React applications, maintaining clean, readable, and consistent code is critical. One common area where issues arise is with the displayName property in React components. While the default ESLint rules for React provide checks for the presence of a displayName, they lack an autofix feature, leaving developers to manually resolve violations. This process can be tedious and error-prone, especially in large codebases with numerous components.

Although some modern bundlers offer support for automatic inlining of the displayName property, this solution is far from universal. The implementation of this feature varies between bundlers, and not all developers or teams can rely on it due to compatibility constraints or specific project configurations. In contrast, ESLint rules have the advantage of being framework-agnostic and widely adopted, making them a more universally accessible solution.

Additionally, we aim to support all types of component decorators, such as observer from the mobx-react library or reatomComponent from the @reatom/npm-react package. These decorators are commonly used in React projects to enhance components with additional functionality, and it is crucial that any solution works seamlessly with them. Moreover, it is necessary to handle nested decorators, like wrapping a component with both memo and forwardRef, for example, memo(forwardRef(() => <div />)). Such scenarios are common in modern React development and should not disrupt the process of assigning meaningful displayName properties.

Another critical aspect is the importance of using named functions rather than relying solely on the displayName property. Named functions improve the clarity of error stack traces, making it easier to debug issues. Assigning a displayName manually can lead to inconsistencies and ambiguity in stack traces, particularly in complex applications with nested components or higher-order components.

In summary, our motivation is to address these challenges by providing a comprehensive and universal approach that ensures consistent displayName handling across various React projects. By automating the process and supporting complex use cases, we aim to save developers time, reduce errors, and improve the overall debugging experience. 1