Create a React application from scratch (Part 4): Enforcing a Style Guide

This post is part of a beginner-level series of posts meant for people who use
ready-made tools, templates or boilerplates for React but wish to learn and understand how to build a React application from the very beginning.

All posts in this series:
Part 1: Introduction
Part 2: Initialization and the First File
Part 3: Using ES2015 Syntax
Part 4: Enforcing a Style Guide
Part 5: Setting up an Express Server
Part 6: Using a Module Bundler
Part 7: Setting up React and Best Practices
Part 8: Setting up Redux
Part 9: Setting up React Router
Part 10: TDD and Setting up Jest

The problem

When it comes to code, everyone writes differently and everyone has an opinion. This is ok as long as you are working on your code and I am working on mine.

It is true that no one intends to write bad, ugly and inconsistently styled code, but it just happens with time and it is more likely to happen when there are more than one developer on the team working on the same code.

Imagine twenty, thirty or even a hundred developers working on the same codebase. Things will get messy very quickly. So what can we do to avoid this?

You need a Style Guide, period.

A style guide is a set of standards that outline how code should be written and organised. In order to enforce a style guide, you would need a code linter.
A code linter is a program that helps save time and write clean and maintainable code by analysing your code for potential errors.

ESLint for code linting

ESLint is the most popular JavaScript linting tool out there and it has plugins for many popular editors like VSCode, Sublime Text and Atom to provide realtime code linting.

Realtime code linting for Visual Studio Code

Let us start setting up ESLint by adding the package to our project as a development dependency:

$ npm install --save-dev eslint

ESLint can be configured using a .eslintrc file. Create this file at the top level of your project and modify its contents so it looks like this:

{
  "env": {
    "es6": true,
    "browser": true,
    "node": true
  }
}

The env configuration key basically tells ESLint which environments our script is designed to run in. Each environment brings with it a certain set of predefined global variables.

What we have done here is that we enabled the browser and Node.js environments and enabled ES6 (ES2015) features so that the linter would not throw errors or warnings when we use browser specific global variables in our code (such as document and window).

AirBnB’s Style Guide

If you do not already have a style guide to follow, then you should definitely adopt AirBnB’s style guide. It is a very comprehensive set of coding standards and it is one of the most popular style guides on the internet.

Install the package from npm as a development dependency:

$ npm install --save-dev eslint-config-airbnb

AirBnB’s style guide requires other packages to be installed, so let us add them as well:

$ npm install --save-dev eslint-plugin-import
$ npm install --save-dev eslint-plugin-jsx-a11y
$ npm install --save-dev eslint-plugin-react

Now, you need to declare that you will use the style guide in your .eslintrc file:

{
  "extends": "airbnb",
  "env": {
    "es6": true,
    "browser": true,
    "node": true
  }
}

A Style Guide is not a blood oath

Your book of law is what your team agrees to follow. You do not have to follow AirBnB’s guide to the letter, you can override their rules (as long as you agree on this with your team) by defining a rules key in your .eslintrc file.

{
  ...
  "rules": {
    "react/jsx-filename-extension": 0,
    "react/forbid-prop-types": 0
  },
  ...
}

Even though you might be tempted to turn off many rules that you think are not reasonable or necessary, it is recommended that you resist this temptation and learn why was this rule added in the first place instead of turning it off just for the sake of staying in your comfort zone.

Linting non-standard ES2015 syntax

Some ES2015 features such as class properties are really useful but they might not be part of the standards (yet) and ESLint will throw a Parsing Error when we use them. To get around this, we are going to use an ESLint parser that allows linting valid Babel code.

Install the package as a development dependency:

$ npm install --save-dev babel-eslint

Then use it in the .eslintrc file:

{
  "parser": "babel-eslint",
  ...
}

Adding an npm script for linting

If you open index.js file now, you would see that ESLint has already spotted problems in our code.

ESLint has spotted problems in the code

The realtime linting features that the code editor plugin offers is essential, but we still need a way to lint the code without using a plugin. Let us create a ‘lint’ script by modifying package.json file:

{
  ...
  "scripts": {
    "start": "babel-node index.js",
    "lint": "eslint . --ext .js,.jsx",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  ...
}

Now if you run the following command in the terminal, you would get the same errors and warnings:

$ npm run lint

Linting errors reported by ESLint

Enforce linting before making a commit

If you are using Git (and you should), you can enforce code linting before each commit by using a pre-commit hook installer. It lets you to run specific scripts before allowing commits to be made. We are going to use it to run the ‘lint’ npm script to ensure inconsistent code does not find its way to the codebase.

Add the package as a development dependency:

$ npm install --save-dev pre-commit

The only thing you need to do is add a pre-commit array to your package.json file that specifies which scripts you want to have ran and in which order. We only want to run one script for now so let us add it:

{
  ...
  "pre-commit": [
    "lint"
  ]
  ...
}

Remember that we have problems in index.js file? If you try to commit the code now, the commit will fail until all these problems are fixed.

ESLint was reporting that there is a missing trailing comma on line 3, a new line was required at the end of the file and there was a warning about using console.log in the code.

After fixing all linting errors, you should be able to commit your changes successfully.

Directory structure should look like this by now

Conclusion

Writing consistent and clean code is very important and this can be achieved by following a style guide. AirBnB’s style guide is one of the most popular style guides on the internet.

Was this article useful? Please click the Clap button below, or follow me for more.

Thanks for reading! If you have any feedback, leave a comment below.

Go to Part 5: Setting up an Express Server