As mentioned previously, one of the main reasons ESLint is popular is because it is extensible with plugins; the most important one for us is eslint-plugin-react.

ESLint can parse JSX without any plugins (just by enabling the flag), but we want to do more. For example, we may want to enforce one of the best practices we have seen in the previous section and keep our templates consistent across developers and teams.

To use the plugin, we first have to install it:

  npm install --global eslint-plugin-react

Once it is installed, we instruct ESLint to use it by adding the following line to the configuration file:

  "plugins": [ 
    "react" 
  ]

As you can see, it is pretty straightforward, and it does not require any complex configuration or set up. Just like ESLint, without any rules it doesn't do anything, but we can enable the recommended configuration to activate a basic set of rules.

To do that, we update the "extends" key in our .eslintrc file as follows:

  "extends": [ 
    "eslint:recommended",  
    "plugin:react/recommended" 
  ]

Now, if we write something wrong, for example, we try to use the same prop twice in a React component, we are going to get an error:

<Foo bar bar /> 

The preceding code returns the following:

No duplicate props allowed (react/jsx-no-duplicate-props) 

There are a lot of rules available to be used in our project. Let's go through some of them and see how they can help us to follow the best practices.

As discussed in the previous chapter, it is very helpful to indent our JSX following the tree structure of the elements to improve the readability.

The problem comes when the indentation is not consistent through the code base and components.

So, here is an example of how ESLint can be useful to help everyone in the team follow a style guide without having to memorize it.

Notice how, in this case, having the wrong indentation is not an actual error and the code works; it is just a matter of consistency.

First of all, we have to activate the rule:

"rules": { 
  "react/jsx-indent": [2, 2] 
}

The first 2 means that we want ESLint to raise an error in case the rule is not followed within the code, and the second 2 means that we want every JSX element to be indented with two spaces. ESLint does not make any decisions for you, so it is up to you to decide which rules to enable. You can even choose to force a non-indentation using 0 as a second parameter.

Write something like the following:

<div> 
  <div /> 
</div>

ESLint complains, as follows:

Expected indentation of 2 space characters but found 0 
    (react/jsx-indent)

A similar rule regards the way we indent our attributes when we write them on a new line.

As we have seen in the previous section, when the attributes are too many or too long, it is a good practice to write them on a new line.

To enforce formatting where the attributes are indented by two spaces in relation to the element name, we can just enable the following rule:

"react/jsx-indent-props": [2, 2]

From now on, if we do not indent the attributes with two spaces, ESLint will fail.

The question is, when do we consider a line too long? How many attributes are too many? Every developer will have a different opinion about this. ESLint helps us to maintain consistency with the jsx-max-props-per-line rule so that every component is written in the same way.

The React plugin for ESLint not only gives us some rules to write better JSX, but also some rules to write better React components.

For example, we can enable a rule to enforce the sorting of the prop types into alphabetical order, a rule to give us an error when we are using a prop that has not been declared, a rule to force us to prefer stateless functional components over classes (we will see the difference in detail in Chapter 3, Create Truly Reusable Components), and so on.