It seems to be obvious, but I found myself a bit confused about when to use curly braces for importing a single module in ES6. For example, in the React-Native project I am working on, I have the following file and its content:

Similar errors also happen to my components with the curly braces. I was wondering when I should use curly braces for a single import, because obviously, when importing multiple component/modules, you have to enclose them in curly braces, which I know.

Edit:

The SO post at here does not answer my question, instead I am asking when I should or should not use curly braces for importing a single module, or I should never use curly braces for importing a single module in ES6 (this is apparently not the case, as I have seen single import with curly braces required)

The default exports tend to be used for whatever you normally expect to get from the module. The named exports tend to be used for utilities that might be handy, but aren’t always necessary. However it is up to you to choose how to export things: for example, a module might have no default export at all.

Is there any downfall to having a module have individual exports export const myA = 43; export const Something = 44; as well as a export default { myA, Something } ? So when you import you can either import A from './A'; for everything in the module, or import { Something } from './A'; so you only get a some of the module
– MichaelFeb 13 '17 at 18:41

8

It is fine, but there is already a syntax for grabbing all named exports into a single object: import * as AllTheThings.
– Dan AbramovMar 4 '17 at 12:08

53

Clearly explained! I wish I could double up vote this answer.
– WillaApr 14 '17 at 20:29

4

what about this- import 'firebase/storage'; or import 'rxjs/add/operator/map';. What is that actually doing?
– kywSep 24 '17 at 7:52

5

@kyw: This executes the module but ignores the exported value. Useful for side effects.
– Dan AbramovFeb 12 '18 at 2:33

Dan Abramov answer above explains about the default exports and named exports.

Which to use?

Quoting David Herman: ECMAScript 6 favors the single/default export style, and gives the sweetest syntax to importing the default. Importing named exports can and even should be slightly less concise.

However in TypeScript named export is favored because of refactoring. Example, if you default export a class and rename it, the class name will change only in that file and not in the other references, with named exports class name will be renamed in all the references.
Named exports is also preferred for utilities.

Overall use whatever you prefer.

Additional

Default export is actually a named export with name default, so default export can be imported as:

The Additional line is good information. import A from './A' doesn't make sense if you're exporting without defining a name like export default 42.
– PGTFeb 24 '17 at 4:53

6

Please make sure not to misinterpret David Herman's quote. It does not mean "It is favoured to always use single/default exports in ES6", but rather "Because single exports are so common, ES6 supports defaults best and we gave them the sweetest syntax".
– BergiMay 16 '17 at 16:42

The type of export (i.e. named or default exports) affects how to import something:

For a named export we have to use curly braces and the exact name as the declaration (i.e. variable, function, or class) which was exported.

For a default export we can choose the name.

Syntax:

// Module B, imports from module A which is located in the same directory
import { importantData_1 , importantData_2 } from './A'; // for our named imports
// syntax single named import:
// import { importantData_1 }
// for our default export (foo), the name choice is arbitrary
import ourFunction from './A';

Things of interest:

Use a comma separated list within curly braces with the matching name of the export for named export.

Use a name of your choosing without curly braces for a default export.

Aliases:

Whenever you want to rename a named import this is possible via aliases. The syntax for this is the following:

import { importantData_1 as myData } from './A';

Now we have imported importantData_1 but the identifier is myData instead of importantData_1.