Linters may not be as powerful as compilers — since they can’t add new language features — but they’re pretty good at features. And sometimes, taking away features can be just as powerful as adding them. taking away This observation is especially true when we talk about . Encapsulation is about , aka information. A lot of encapsulation features are implemented at the language level, such as function scoping and module scoping. But when we want even more encapsulation than what the language provides, linters are a good fit to take over. encapsulation information hiding taking away Let’s look at some examples where ESLint provides us with encapsulation even while ES6 provides none. Encapsulating the Browser API If you need to support server-side rendering, then you’ll have to make sure that your code can run in a server environment, where there won’t be any browser-specific global variables like , , etc. Thankfully, ESLint allows us to configure the global variables for a given file: window location ReactDOM.render(  <App />,  document.getElementById('root')); // flagged by linter

/* eslint-env browser */ This way, we can the browser API from all modules, except the specific modules that need them. We can do the same for ! hide other environments too Encapsulating Modules Let’s say that we want to centralize all requests in our codebase to one file called . We’re probably using a single networking client for this, like for example. We can enforce this by making sure that no one in the codebase can import Axios except for our file. network api.js Axios api.js We’ll use the lint rule to disallow other modules from importing Axios by adding this to our : no-restricted-modules .eslintrc {    "no-restricted-modules": ["error", "axios"]} and then disable it just for our file: api.js This way, we can networking functionality from all modules, except the specific modules we whitelist. hide Encapsulating Classes Let’s say we want a private method in our class. Unfortunately, there’s no keyword for us to use for enforcing this rule, but we can use ESLint’s rule to a similar effect: Javascript private no-underscore-dangle class MyClass {_myPrivateMethod() {} myPublicMethod() {}} const instance = MyClass()instance._myPrivateMethod(); // flagged by linter Lint Rules are Traffic cones All of the above encapsulations are easy to break. Static analysis tools like linters can’t protect against dynamic language features like , or , and that’s fine. Lint rules are more like traffic cones than concrete walls. require('axios') instance['_myPrivateMethod']() The idea isn’t to guard against willful violations of these rules. It’s to align the path of least resistance with best practices, and that’s usually good enough. is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Facebook

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Using ESLint for Encapsulation

Too Long; Didn't Read

Company Mentioned

Abdul Nimeri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Using ESLint for Encapsulation

Too Long; Didn't Read

Company Mentioned

Abdul Nimeri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES