Why it says: Default exports in JavaScript modules suck

This article was first published on the WeChat public account: Big Move to the World, my WeChat: qq449245884, I will share with you the front-end industry trends, learning methods, etc. as soon as possible.
For more open source works, please see GitHub https://github.com/qq449245884/xiaozhi , including the complete test sites, materials and my series of articles for interviews with first-tier manufacturers.

We know that JavaScript modules have two ways to define exports: default exports and named exports. In this section, we look at why exporting by default is a bad practice and can lead to a bad development experience.

Next, let's look at an example. Suppose, we have a module that contains both named exports and default exports, as follows:

 export const add = (a, b) => a + b;

export default subtract = (a, b) => a - b;

Before importing to use, there is a problem here, it may affect our development experience. Why is subtract the default and add a named export?

ps: The example I gave may be a bit deliberate, but with the complexity of the module, there are often cases like this

Consider that the developers use a module they are unfamiliar with and complex. They may not know what methods are exported by default, or even if there is a default export. This causes developers to spend more time reading documentation or source code. If the module only has named exports, it is more convenient to use and more readable.

With named exports, using the IDE, we can easily know what methods a module has. So, what doesn't this list below show? Yes, it is exported by default. Remember, the default export is not a named export, so the IDE doesn't know what to change the default export, and it won't show up in the prompt list:

The development experience of the default export is similar to CommonJS in Node, and its development experience is not very friendly. An easy way to tell if your code uses CommonJS is to see if it uses require and module.exports .

Let's introduce some usages (slots) of the default export:

• The default export name can be named whatever we want. That is, the subtraction function you can name multiplication. This can lead to confusion, especially as code complexity increases.

 import multiply from './math.js';
const result = multiply(2, 2);  // results is now 0

• Since the default export can use any name, and each developer's naming habits are different, the names are different, so there is no consistency.
• The default export is also not good for refactoring. In the named export, if our method name is changed one day, the IDE will prompt us that the corresponding method does not exist, and we can refactor it better. There is no feedback from the IDE for default exports.

At this point, you may have a question, what if two named exports from different modules have the same name?

We can use renaming to solve this problem:

 import { Article } from './types';
import { Article as ArticleComponent } from 'my-design-system';

While this way still requires thinking of a name for the alias, this is much better than thinking of a name for the default export, since there are named exports for reference.

Finally, you might also be thinking, "The framework or tool I use almost requires us to export a function or component by default". If there are many components, we can solve this problem by using "index.js". Just create a index.js or index.ts file at the root of the directory, and then export these components with a name.

For example, we have a file components , which mainly places our packaged components:

 src/ 
  components/
   com1/
     index.vue
   com2/
     index.vue

Then we can create a index.js file in components 1c487ae05ab9db764c1e4e451e4dc967--- with the following content:

 export { default as Com1 } from './com1'
xport { default as Com2 } from './com2'

In this way, we use the named export method to import and use it in other files:

 import { Com1, Com2 } from '@/components'

If you're writing a module, whether it's a codebase or an open source library, try to use as few default exports as possible.

That's it.

Source: https://www.lloydatkinson.net/posts/2022/default-exports-in-javascript-modules-are-terrible/

The bugs that may exist after the code is deployed cannot be known in real time. In order to solve these bugs afterwards, a lot of time is spent on log debugging. By the way, I recommend a useful bug monitoring tool , Fundebug .

comminicate

If you have dreams and dry goods, you can search for [Great Move to the World] on WeChat and pay attention to this Shawanzhi who is still washing dishes in the early hours of the morning.

This article GitHub https://github.com/qq449245884/xiaozhi has been included, there are complete test sites, materials and my series of articles for interviews with first-line manufacturers.