Why and when to use default export over named exports in es6 Modules?

冷暖自知 提交于 2020-03-13 04:24:51

问题


I have referred all the questions in stackoverflow. But none of the suggested why and when to use default export.

I just saw that default can be metioned "When there is only one export in a file"

Any other reason for using default export in es6 modules?


回答1:


Some differences that might make you choose one over the other:

Named Exports

  • Can export multiple values
  • MUST use the exported name when importing

Default Exports

  • Export a single value
  • Can use any name when importing

This article does a nice job of explaining when it would be a good idea to use one over the other.




回答2:


With named exports, one can have multiple named exports per file. Then import the specific exports they want surrounded in braces. The name of imported module has to be the same as the name of the exported module.

// imports
// ex. importing a single named export
import { MyComponent } from "./MyComponent";

// ex. importing multiple named exports
import { MyComponent, MyComponent2 } from "./MyComponent";

// ex. giving a named import a different name by using "as":
import { MyComponent2 as MyNewComponent } from "./MyComponent";

// exports from ./MyComponent.js file
export const MyComponent = () => {}
export const MyComponent2 = () => {}

You can also alias named imports, assign a new name to a named export as you import it, allowing you to resolve naming collisions, or give the export a more informative name.

import MyComponent as MainComponent from "./MyComponent";

You can also Import all the named exports onto an object:

import * as MainComponents from "./MyComponent";
// use MainComponents.MyComponent and MainComponents.MyComponent2 here

One can have only one default export per file. When we import we have to specify a name and import like:

// import

import MyDefaultComponent from "./MyDefaultExport";

// export

const MyComponent = () => {}

export default MyComponent;

The naming of import is completely independent in default export and we can use any name we like.

From MDN: Named exports are useful to export several values. During the import, one will be able to use the same name to refer to the corresponding value. Concerning the default export, there is only a single default export per module. A default export can be a function, a class, an object or anything else. This value is to be considered as the “main” exported value since it will be the simplest to import.




回答3:


1st Method:-

export foo; //so that this can be used in other file

import {foo} from 'abc'; //importing data/fun from module

2nd Method:-

export default foo;  //used in one file

import foo from 'blah'; //importing data/fun from module

3rd Method:-

export = foo;

import * as foo from 'blah';

The above methods roughly compile to the following syntax below:-

//all export methods

exports.foo = foo; //1st method
exports['default'] = foo; //2nd method
module.exports = foo; //3rd method

//all import methods

var foo = require('abc').foo; //1st method
var foo = require('abc')['default']; //2nd method
var foo = require('abc'); //3rd method

For more information, visit to Default keyword explaination

Note:- There can be only one export default in one file.

So whenever we are exporting only 1 function, then it's better to use default keyword while exporting




回答4:


It's somewhat a matter of opinion, but there are some objective aspects to it:

  • You can have only one default export in a module, whereas you can have as many named exports as you like.

  • If you provide a default export, the programmer using it has to come up with a name for it. This can lead to inconsistency in a codebase, where Mary does

    import foo from "./foo";
    

    ...but Joe does

    import getFoo from "./foo";
    

    In constrast, with a named export, the programmer doesn't have to think about what to call it unless there's a conflict with another identifier in their module. It's just

    import { foo } from "./foo";
    

    ...(with an as getFoo if necessary to avoid a conflict).

  • With a named export, the person importing it has to specify the name of what they're importing, which means they get a nice early error if they try to import something that doesn't exist.

  • If you consistently only use named exports, programmers importing from modules in the project don't have to think about whether what they want is the default or a named export.




回答5:


There aren't any definitive rules, but there are some conventions that people use to make it easier to structure or share code.

When there is only one export in the entire file, there is no reason to make it named. Also, when your module has one main purpose, it could make sense to make that your default export. In those cases you can extra named exports

In react for example, React is the default export, since that is often the only part that you need. You don't always Component, so that's a named export that you can import when needed.

import React, {Component} from 'react';

In the other cases where one module has multiple equal (or mostly equal) exports, it's better to use named exports

import { blue, red, green } from 'colors';


来源:https://stackoverflow.com/questions/46913851/why-and-when-to-use-default-export-over-named-exports-in-es6-modules

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!