12 important ESLint guidelines for React

Introduction

ESLint has a complete algorithm for JavaScript code that cowl stylistic decisions and forestall widespread bugs. Utilizing ESLint alone will give your undertaking a lift, however there are ESLint plugins accessible so as to add React-specific guidelines that may provide help to write strong React functions.

On this publish, we’ll go over these ESLint guidelines and plugins, together with as they apply to Hooks. Listed below are some fast hyperlinks so that you can leap round:

React Hooks guidelines (eslint-plugin-react-hooks)

This plugin solely comprises two guidelines, however they’re crucial to avoiding widespread pitfalls when writing operate elements with Hooks.

react-hooks/rules-of-hooks

This rule enforces that elements observe the Guidelines of Hooks when utilizing Hooks. The foundations are mentioned intimately within the React documentation, however there are two guidelines that should be adopted when utilizing Hooks:

1. Hooks ought to solely be referred to as from the top-level code of your element. What this actually means is that the Hooks shouldn’t be referred to as conditionally — they need to as a substitute be referred to as on each render, in the identical order, to keep away from points and refined bugs
2. Hooks ought to solely be referred to as from both a operate element, or one other Hook
   1. Customized Hooks usually compose habits collectively from inbuilt, and even different customized, Hooks

Within the default configuration, violations of this rule will trigger an error, inflicting the lint verify to fail.

react-hooks/exhaustive-deps

This rule enforces sure guidelines concerning the contents of the dependency array that’s handed to Hooks, equivalent to useEffect, useCallback, and useMemo. Typically, any worth referenced within the impact, callback, or memoized worth calculation should be included within the dependency array. If this isn’t executed correctly, points equivalent to out-of-date state information or infinite rendering loops may result.

This rule is nice at discovering potential dependency-related bugs, however there are some limitations:

• Customized Hooks with dependency arrays won’t be checked with this rule. It solely applies to the inbuilt Hooks
• The rule can solely correctly verify dependencies if it’s a static array of values. If a reference to a different array is used, or one other array is unfold into it, the rule will emit a warning that it can’t decide the dependencies

This rule has been considerably controversial; there are a number of lengthy concern threads on GitHub, however the React crew has been good about soliciting and incorporating suggestions. Within the default configuration, violations of this rule are handled as warnings.

The small print of this rule might take up a complete article on their very own. For a deeper dive on this rule and the best way to correctly use it, see the Understanding the React exhaustive-deps linting warning article, right here on the LogRocket weblog.

React guidelines (eslint-plugin-react)

This plugin comprises much more guidelines (100 guidelines at time of writing) which can be particular to the core of React. Most guidelines cowl common React practices, and others cowl points associated to JSX syntax. Let’s check out among the extra helpful ones.

react/button-has-type

For accessibility causes, most clickable parts in a element that aren’t easy hyperlinks to a different URL ought to be carried out as buttons. A standard mistake is to omit the sort attribute from these buttons after they aren’t getting used to submit a type.

When no sort is specified, a button defaults to a kind of submit. This could trigger points for buttons that descend from a type aspect. Clicking such a button within a type will trigger a probably undesirable type submission.

Motion buttons that aren’t supposed to submit a type ought to have a sort attribute of button.

This rule enforces that every one buttons explicitly have a sort attribute — even ones which can be supposed as Submit buttons. By being express, unintentional submissions are prevented and the intent of the code is evident.

react/prop-types

Requires that every one React elements have their props described in a PropTypes declaration. These checks solely throw errors in growth mode however can assist catch bugs arising from the incorrect props being handed to a element.

In case your undertaking makes use of TypeScript, this rule can also be happy by including a kind annotation to the element props that describes them.

These two approaches are lined intimately in Evaluating TypeScript and PropTypes in React functions by Dillion Megida.

react/require-default-props

Relying on the element, some props could also be required whereas others are non-compulsory. If an non-compulsory prop isn’t handed to a element, it will likely be undefined. This can be anticipated however can introduce bugs if the worth isn’t checked.

This rule requires that each non-compulsory prop is given a default worth within a defaultProps declaration for the element. This default worth might be explicitly set to null or undefined if that’s what the element expects.

With operate elements, there are two completely different methods that can be utilized to verify default props:

defaultProps

This technique expects the operate element to have a defaultProps object with the defaults.

const MyComponent = ({ motion }) => { ... }

MyComponent.propTypes = {
  Motion: PropTypes.string;
};

MyComponent.defaultProps = {
  motion: 'init'
};

defaultArguments

This technique expects the defaults to be specified within the operate declaration, utilizing JavaScript’s inbuilt default values syntax.

const MyComponent = ({ motion = 'init' }) => { ... }

MyComponent.propTypes = {
  Motion: PropTypes.string;
};

Should you use the defaultArguments technique, there shouldn’t be a defaultProps object. If there may be, this rule will fail.

react/no-array-index-key

When rendering a listing of things in React, we sometimes name map on an array, and the mapping operate returns a element. To maintain monitor of every merchandise within the listing, React wants these elements to have a key prop.

A standard pitfall with rendering lists is utilizing the array index as the important thing. This could trigger pointless and even incorrect renders. The React documentation advises in opposition to this apply as a result of points it could possibly trigger (there may be additionally a extra detailed dialogue about how keys are used). A key’s anticipated to be a singular identifier for that merchandise, inside the listing, that doesn’t change, like the first key worth in a database row.

This rule ensures that the array index isn’t used as the important thing.

react/react-in-jsx-scope

Take into account this easy React element:

const Greeter = ({ title }) => <div>Whats up {title}!</div>;

The React object isn’t referenced in any respect. Nevertheless, React nonetheless must be imported or else you’ll encounter an error. That is as a result of transpilation strategy of JSX. Browsers don’t perceive JSX, so through the construct course of (normally with a software equivalent to Babel or TypeScript), the JSX parts are reworked into legitimate JavaScript.

This generated JavaScript code calls React.createElement instead of JSX parts. The above element could be transpiled to one thing like this:

const Greeter = ({ title }) => React.createElement("div", null, "Whats up ", title, "!");

The references to React listed here are why React should nonetheless be imported. This rule ensures that every one recordsdata with JSX markup (not essentially even a React element) have React in scope (sometimes via an import or require name).

react/jsx-uses-react

All the time importing React is important for correct transpilation, however when ESLint seems on the file, it’s nonetheless JSX, so it received’t see React referenced anyplace. If the undertaking is utilizing the no-unused-vars rule, this leads to an error since React is imported however not used anyplace.

This rule catches this case and prevents no-unused-vars from failing on the React import.

react/display-name

For correct debugging output, all React elements ought to have a show title. In lots of instances, this received’t require any additional code. If a element is a named operate, the show title would be the title of the operate. Within the under examples, the show title of the element shall be MyComponent.

• const MyComponent = () => { … }
• const MyComponent = operate() { return …; }
• export default operate MyComponent() { return …; }

There are some instances the place the automated show title is misplaced. That is sometimes when the element declaration is wrapped by one other operate or greater order element, like within the two examples under:

• const MyComponent = React.memo(() => { … });
• const MyComponent = React.forwardRef((props, ref) => { … });

The MyComponent title is sure to the brand new “outer” element returned by memo and forwardRef. The element itself now has no show title, which is able to trigger this rule to fail.

When these instances come up, a show title might be manually specified through the displayName property to fulfill the rule:

const MyComponent = React.memo(() => { ... });
MyComponent.displayName="MyComponent";

react/no-children-prop

React elements settle for a particular prop referred to as kids. The worth of this prop shall be no matter content material is contained in the opening and shutting tags of the aspect. Take into account this easy MyList element:

const MyList = ({ kids }) => {
  return <ul>{kids}</ul>;
};

This can render the outer ul aspect, and any kids we put contained in the aspect shall be rendered within it.

<MyList>
  <li>item1</li>
  <li>item2</li>
</MyList>

That is the popular sample with React elements. It’s attainable, although not really useful, to cross kids as an express kids prop:

<MyList kids={<li>item1</li><li>item2</li>} />

The above utilization will really trigger an error as a result of JSX expressions, just like the one handed as the express kids prop, will need to have a single root aspect. This requires the kids to be wrapped in a fraction:

<MyList kids={<><li>item1</li><li>item2</li></>} />

As proven within the first instance, kids are handed as baby parts to the element instantly, so the element is the basis aspect of the expression. No fragment or different enclosing aspect is required right here.

That is primarily a stylistic selection/sample, however it does forestall inadvertently passing each an express kids prop and baby parts:

<MyList kids={<><li>item1</li><li>item2</li></>}>
  <li>item3</li>
  <li>item4</li>
</MyList>

On this case, the kid parts (item3 and item4) can be displayed, however item1 and item2 wouldn’t. This rule ensures that kids are solely handed within the idiomatic manner, as baby JSX parts.

react/no-danger-with-children

React’s dangerouslySetInnerHTML prop permits arbitrary markup to be set because the innerHTML property of a component. That is usually not really useful, as it could possibly expose your utility to a cross-site scripting (XSS) assault. Nevertheless, if you recognize you possibly can belief the enter and the use case requires it, this strategy could turn into needed.

The prop expects an object with an __html property, whose worth is a uncooked HTML string. This string shall be set because the innerHTML.

As a result of this replaces any current baby content material, it doesn’t make sense to make use of this together with a kids prop. In reality, React will throw an error if you happen to try to do that. In contrast to some errors that solely seem in growth mode (like PropTypes validation errors), this error will crash your app.

This rule enforces the identical rule. If dangerouslySetInnerHTML is used with kids, the lint rule will fail. It’s a lot better to catch these errors when linting, or at construct time, moderately than reported by customers as soon as the app is deployed!

react/jsx-no-bind

Each time a React element is rendered, it comes at a efficiency price. Oftentimes, sure patterns or practices could cause a element to unnecessarily re-render itself. There are various causes for this habits, and this rule helps forestall certainly one of them.

When any operate is outlined contained in the element, it will likely be a brand new operate object on each render. Which means each time the element is re-rendered, the prop is taken into account modified. Even with React.memo, the element will re-render.

If the kid element has any useEffect calls that take that operate as a dependency, this will trigger the impact to run once more, creating the potential for an infinite loop that may possible freeze the browser.

With this rule enabled, any operate that’s handed as a prop shall be flagged.

There are two methods this may be addressed. If the operate doesn’t rely upon the rest contained in the element, it may be moved exterior of the element, the place it’s only a plain operate that may at all times be the identical reminiscence reference. This ensures that the identical operate is handed to the prop every time.

For instances the place the operate does rely upon the element ultimately, the standard repair for that is to memoize it with the useCallback Hook. Any properties referenced within the operate should be included within the useCallback dependency array; typically this requires a number of ranges of memoization of values or capabilities.

This provides some complexity, however has the good thing about serving to to cut back additional renders and forestall infinite loops.

Wrapping up

The foundations lined listed here are only a few of those offered by the eslint-plugin-react plugin. Some guidelines might be opinionated or overzealous, however most even have configuration choices to make them much less strict.

There may be additionally one other very useful ESLint plugin centered round JSX and accessibility practices: eslint-plugin-jsx-a11y. The foundations on this plugin verify your JSX markup to make it possible for good HTML accessibility practices are being adopted.

These React ESLint plugins might be useful to keep away from widespread pitfalls, particularly if you happen to’re nonetheless new to React. You may even write your personal guidelines and plugins to cowl different conditions!