DEV Community

Cover image for Code Smell | Too Many Imports
Jesús Mejías Leiva for Product Hackers

Posted on • Updated on • Originally published at blog.susomejias.dev

Code Smell | Too Many Imports

Hello, today I am writing again and this time I am going to introduce you to how we incur in a very common code smell called Too Many Import, is caused by the abusive use of imports in components, classes or any other type of module of our project.


Cause

It seems like a very harmless Code Smell but it can indicate that we are breaking very important principles such as:

  • Coupling
  • Low cohesion
  • Violation of the SRP (Single Responsibility Principle)

Example

In the following example we can see how up to 13 imports are carried out, which should lead us to think if our component does not have too many responsibilities:

import one from "...";
import two from "...";
import three from "...";
import four from "...";
import five from "...";
import six from "...";
import seven from "...";
import eight from "...";
import nine from "...";
import ten from "...";
import eleven from "...";
import twelve from "...";
import thirteen from "...";


export default function Example() {
  //... code
}


Enter fullscreen mode Exit fullscreen mode

Solutions

  1. In the first place, it may seem a bit obvious, but we should review the use of these imports and assess if they are all essential for the correct functioning of the component.

  2. As you can imagine, the solution to this involves separating responsibilities and dividing this component into several smaller ones or even extracting logic to hooks, although in this case, in order not to introduce many concepts, we will propose a solution based on dividing it into several smaller components:

FirstComponent

import one from "...";
import two from "...";
import three from "...";
import four from "...";
import five from "...";

export default function FirstComponent() {
  //... code
}
Enter fullscreen mode Exit fullscreen mode

SecondComponent

import six from "...";
import seven from "...";
import eight from "...";
import nine from "...";

export default function SecondComponent() {
  //... code
}
Enter fullscreen mode Exit fullscreen mode

ThirdComponent

import ten from "...";
import eleven from "...";
import twelve from "...";
import thirteen from "...";

export default function ThirdComponent() {
  //... code
}
Enter fullscreen mode Exit fullscreen mode

Finally the ExampleComponent , it would stay like this:

import FirstComponent from "./FirstComponent";
import SecondComponent from "./SecondComponent";
import ThirdComponent from "./ThirdComponent";

export default function Example() {
  //... code
}
Enter fullscreen mode Exit fullscreen mode

We can see that we have reduced the number of import by a large number, but this does not end here, by making this division we are delegating the responsibilities to each component.


Warning!

Therefore, like every Code Smell, this one must be carefully analyzed before applying any solution, since a hasty decision can cause some side effects.

Not all are advantages, below we will see some disadvantages that we must consider when applying these splits:

  • In some cases we can incur in a premature optimization, especially in small projects that do not need much maintenance.

  • They can have many components, classes etc if the project has considerable dimensions.


Bonus Track

To help us take more into account the number of imports we can use our linter, for example in the case of using eslint we have a rule inside the eslint-plugin-import plugin called import/max-dependencies
which we can configure to help us with this smell.


Thanks for reading me 😊

Oldest comments (0)