Like any kind of apps, JavaScript apps also have to be written well.
Otherwise, we run into all kinds of issues later on.
In this article, we’ll look at some best practices for importing items.
No Useless Path Segments
We shouldn’t have useless path segments in our imports.
It just makes the imports more complex than it should be.
For instance, if we have:
import "./../pages/about.js";
Then /.. and /pages cancel each other out.
Therefore, we don’t need the 2 segments.
Likewise, we shouldn’t have a slash at the end since it’s useless.
So we shouldn’t have:
import "./pages/";
Also, we don’t need an extension at the end of the module path.
So we shouldn’t write things like:
import "./pages/foo.js";
Instead, we write:
import "./../pages/about";
and:
import "./pages";
and:
import "./pages/foo";
to get rid of the useless parts.
No Relative Parent Imports
We should prevent imports to folders in a relative parent path.
So if we have something like:
import add from '../add';
Then we should put them in the same folder to simplify the folder structure.
We instead put them in the same folder and write:
import add from './add';
Bad Imports or Exports
There are import and export syntax that isn’t valid.
For instance, we can’t have more than one default export.
So we can write:
export default foo;
export default bar;
And we can’t have multiple named exports with the same name:
export const foo = function () { /*...*/ }
const bar = () => { /*...*/ }
export { bar as foo }
We should make sure that we only have one default export and one named export with a given name.
No Misleading Imports
We shouldn’r have misleading imports.
If we have a default import, then we should name our import with the same name as the module.
This may be done because we forgot the braces.
For instance, if we have:
import bar from './foo';
Then it may be a named import named bar but we forgot to include the braces.
We may also be misleading people intentionally or not with a default import that’s different from the name of the module file.
To make our lives easier, we should name our default imports with the same name as the module file:
import foo from './foo';
No Named as Default Member
We may have a module that has both a default export and one or more named exports.
For instance, we may have the following in foo.js :
export default 'foo';
export const bar = 123;
Then we can write:
import foo, { bar } from './foo';
This may be confusing to some people.
We may want to just have all named exports or only one default export and nothing else in our module.
No Deprecated Imports
If an export has been marked as @deprecated with JSDoc comments, we don’t want to import it since it’s going to be removed in the future.
If we used any deprecated exports in existing code, we should get rid of them as soon as we can.
Don’t Use Extraneous Packages
If we have packages that aren’t used anywhere in our code, then we shouldn’t import them.
So if we have:
const _ = require('lodash');
then we should use Lodsh somewhere.
Ideally, we only import the parts of Lodash that we need.
So we can write:
const { zip } = require('lodash');
Then we only use the zip method in our code instead of importing the whole module, which has hundreds of methods.
No Mutable Exports
We shouldn’t export mutable variables in our code.
For instance, we shouldn’t write things like:
export let count = 1;
let variables can be reassigned to anything.
So the exported value may be changed.
Instead, we use const :
export const count = 1
so that we can’t change our exported value.
Functions and classes can also be exported:
export function getNumbers() {}
export class Counter {}
Conclusion
We shouldn’t export mutable variables.
Also, we shouldn’t have useless path segments to make more imports more complex than they are.
We should make sure that our import/export syntax are valid.
