JavaScript debate : named imports VS default imports
Tags: javascript, discuss, healthydebate, webdev
Published: 2019-10-19 21:51:29

---
title: JavaScript debate : named imports VS default imports
published: true
date: 2019-10-17 04:00:00 UTC
tags: javascript,discuss,healthydebate,webdev
canonical_url: https://mindsers.blog/en/javascript-named-imports-vs-default-imports/
---

 ![JavaScript debate : named imports VS default imports](https://images.unsplash.com/photo-1553731819-3246d25c4f0b?ixlib=rb-1.2.1&q=80&fm=jpg&crop=entropy&cs=tinysrgb&w=1080&fit=max&ixid=eyJhcHBfaWQiOjExNzczfQ)

A debate on the type of import we use in JavaScript has recently appeared. Same kind of debate than the one with semicolon. It works whichever you choose but each developer has its opinion on the matter and nobody agree. I also have an opinion!

***⚠️ Read more of my blog posts about tech and business [on my personal blog](https://mindsers.blog/)! ⚠️***

To make it short : I prefer _named imports_. Long answer is below though.

## What is the difference between default imports and name imports?

It is a very subtil detail as it often is in this kind of debate.


```js
import detectRotation from 'rotate'
```
<figcaption>Default import</figcaption>

This first example consists in trying to import the default symbol of a JavaScript module and store it in a variable that is named `detectRotation`.


```js
import { detectRotation } from 'rotate'
```
<figcaption>Named import</figcaption>

_Named imports_ look less simple. In fact, we are destructuring the module to only import the symbols we need in it.

## Meaning, tools and clean code

If developers argue about import methods, it is because there are more than just syntax differences.

First, _default imports_ are nameless. Or rather : it looses its name during exportation. Be it variables, constants, objects, classes, etc : they all have a name in their module. They are exported as `default` and it becomes their new name sort of.

So when we write :

```js
import detectRotation from 'rotate'
```

we are not importing `detectRotation` inside of `rotate` module but rather we import `default` symbol of the `rotate` module that we rename `detectRotation` in the current module.

And this is one of the main reason why I prefer _named imports_. Because nothing indicates that it is the`detectRotation` function that is exported as `default` in this module.

Whereas, when we write :

```js
import { detectRotation } from 'rotate'
```

it is the `detectRotation` function that I import from the `rotate` module. If this function doesn't exist, my development tools (editor, linter, language services, etc) will let me know in a more or less direct way. Worse case scenario : my import will fail during execution in the JS engine.

Some will say that you just have to read the documentation of the module to know how to use it but I really don't want to research in the documentation each time I come back to the code, like 2 weeks after writing it.

**I think code must be as clear and understandable as possible on its own** and _named imports_ are great for that.

## Communities standards

In several posts about [best practices](https://blog.nathanaelcherrier.com/tag/best-practices/), [linting (fr)](https://blog.nathanaelcherrier.com/fr/linting-good-practices/) and other methodologies, I advise to copy what the community is already doing.

One of the goal of this advice is to simplify team work and better the maintenance of a project. There are a lot more chance that a new dev knows "standard" choice of a community instead of your personal preference...

You could translate this advice in :

> Do what is best for your team, not what is best for you

So what about the "_named import_ vs _default import_" debate? Same old thing here, communities have their own opinion on the matter.

For example, in Angular _named imports_ are widely used. You can see that is the Angular doc. There are (almost) no `default` import or export.


```js
import { ProductAlertsComponent } from './product-alerts.component.ts'
```
<figcaption>a Team Angular import</figcaption>

In the React community, _default imports_ might be used depending on the situation. The thinking behind is a little more complex than just "we're only doing named import" or "we're only doing default import". I think this logic is really interesting so I'll detail just below.

First, the file that contains a component must have the same name as the component. This component is exported as `default`.

Then you can export other useful things to the files of your components. Like hooks, utils, test version of your component...Etc.


```js
import ProductAlerts, { useProducts } from 'ProductAlerts.ts'
```
<figcaption>a Team React import</figcaption>

There are, of course, a few exceptions but that is the majority. Even though I prefer _named imports_ for reasons I listed above in the post, I think this is a very logical way to do things.

Once again, each community works with its preferences and you better make it yours to ease your team working and other aspects of your dev life (code review...etc).