JavaScript’s Loose Standards are a Blessing & a Curse

Clean-er Code: The Wake Up Call

I was a little late to the React party, I only started learning it in earnest, about 10 months ago. Yes, I’d heard about it long before then. Yes, I’d had co-workers, casual acquaintances and the two developers putting out my web dev podcast of choice, Syntax FM, tell me how great it was. Yes, I’d heard Facebook, which at that time had yet to reveal most of its less-than-savory-doings, had created it and kept improving on it.

But as anyone who’s been a web developer for longer than six months knows, there’s an absolute ton of JavaScript frameworks out there that had a brief moment in the sun, only to be obscured weeks or month later by the new hotness. So I sat on my hands, waited to see if React was worth investing my time in learning, and laughed every time this meme came across my Internet feeds.

This image still makes me smile whenever I see it. O’Reilly parody covers are the best.

When it became apparent that React was the new JavaScript powerhouse of choice and wasn’t going away anytime soon, I finally got on board and started teaching it to myself. For the past 10 months or so, I’ve been learning React on the side while supporting an AngularJS 1.5 application at my current company.

And having to work with that monolithic, two-way data binding, AngularJS application, chock full of business logic, while building smaller, cleaner, unidirectional data flow, React side projects reinforced what every one else had been telling me all along. React is way better.

Recently, I was feeling pretty good about my own React / JavaScript knowledge and coding abilities. By no means am I an expert, nor have I used some of React’s most recent advancements like hooks, but I can talk knowledgeably about state and props . I can discuss different lifecycle render methods and what they’re good for. Heck, I can even debate Redux versus the context API for state management, and why things like defined prop types are beneficial.

I’ve written a full-stack, user registration application as a learning tool and I am proud of it. It’s React and ES6 on the front end, Node.js on the backend, and a MySQL database with the Sequelize ORM to handle database interactions. I implemented Passport.js middleware for JWT authentication and Docker Compose to spin the whole application up at once. I also added in password reset via email functionality with Nodemailer and Swagger API endpoint testing.

I’ve done a lot with this little app, learned a lot along the way, and written a lot of articles about my learnings (all linked above). But then, I implemented ESLint into my application, thinking it would be a good way to make sure my code was well written.

And once again, I was humbled and taught how to write better JavaScript code. That’s what I want to talk about today.

ESLint: 21st Century Rules for ES6 JavaScript & Beyond

What is it?

If you’re not familiar with ESLint, you can read this handy post I wrote a few months ago. The post was more to do with using both ESLint and Prettier in the Visual Studio Code IDE to produce consistent, clean code across development teams with little effort on the part of the developers, but it still explains how ESLint works.

In a nutshell:

Linting tools like ESLint allow developers to discover problems with their JavaScript code without executing it. — ESLint site

ESLint is a file in a project repo called .eslintrc with a list of linting rules that runs through the project’s JavaScript code and finds problematic patterns or code that don’t adhere to certain style guidelines set forth by those rules. Then it alerts developers so they can fix it the errors.

It will not (normally) rewrite or reformat code like Prettier. Nor will it tell you if you have bad business logic. But it will tell you if curly braces are missing, return statements are unreachable, or objects / arrays could be destructured, among other things.

Why ESLint is Awesome

This is awesome because not only does ESLint identify ways to make code better, but if you don’t need or don’t agree with certain rules, they can be changed or ignored (either for the line, for the whole file, or for the whole project).

None of the rules depend on each other, they all function independently, and some rules can even fix the code themselves to fall in line with the prescribed rules.

The ESLint rules that Airbnb abides by are considered among many as the gold standard for React. They are strict, they are unforgiving and they are thorough. They are so popular, in fact, that Airbnb created their ESLint config as an NPM package that has over 1 million weekly downloads, as I write this article.

They also have an entire JavaScript style guide on Github that has some very good advice in it for writing code. But that’s a different rabbit hole than the one I’m going down today.

Since I felt like holding myself to high standards (*being a masochist*), I decided to use Airbnb’s ESLint rules as the starting place for my own .eslintrc file for my full stack JavaScript project. Boy, did I learn a lot when I turned on the linter…

Before & After ESLint’s Cold, Brutally Honest Linting

My ESLint Setup & Dev Dependencies

Before I could get linting for my React application going to reveal my own code’s shortcomings, I had to download a few dev dependencies for my package.json file and set up my .eslintrc file.

Dev Dependencies

I used create-react-app to create the initial front end for my full stack application, so I only had a few additional dependencies I needed to add to my package.json file to make Airbnb’s ESLint config work.

npm install --save-dev eslint eslint-config-airbnb eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react

. eslintrc File

Then, once all the package were installed, I set up my .eslintrc file like this.

{

"extends": "airbnb",

"parser": "babel-eslint",

"env":

{

"node": true,

"es6": true,

"browser": true

},

"rules":

{

"react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }],

"implicit-arrow-linebreak": "off",

"comma-dangle": "off",

"indent": "off",

"no-trailing-spaces": "off"

}

}

That’s really all the setup I did. I added "extends": "airbnb" as prescribed by the Airbnb’s documentation, added in that I was transpiling my ES6 code with babel, listed the environments and added a few additional rules to override the Airbnb settings.

Most of these rules were overwritten because I also use Prettier’s code formatting on save in my VS Code setup, and if I didn’t turn off the rules in ESLint, Prettier would continue to reformat code and break the rules every time I saved a file. A minor inconvenience though.

The Rules I Set

I extended the react/jsx-filename-extension rule to apply to files ending in both .js and .jsx because all my files which include JSX end in .js .

rule to apply to files ending in both and because all my files which include JSX end in . I turned off implict-arrow-linebreak because Prettier reformatted it on save.

because Prettier reformatted it on save. I turned off comma-dangle , indent and no-trailing-spaces for the same reason.

Beyond that, there were one-off rules that ESLint highlighted, which I turned off by file or by line when I needed to (such as console.log ). I’m sure you’ll also come upon situations that dictate such exceptions as well.

Without ESLint Enabled

Now, let’s see how my code looked before I enabled ESLint in my project.

Here’s an example of two of my React components. The first is the home page file, the second is the header bar, which is a reusable component across the whole application.