I'm reading through the ES6 import
statement on the MDN docs.
I understand generally how it works, but wanting to dive deeper, I'm not understanding one aspect of the syntax.
As stated in the MDN syntax of import
, these are all of the different way to import code into the current module/scope:
import defaultExport from "module-name";
import * as name from "module-name";
import { export } from "module-name";
import { export as alias } from "module-name";
import { export1 , export2 } from "module-name";
import { foo , bar } from "module-name/path/to/specific/un-exported/file";
import { export1 , export2 as alias2 , [...] } from "module-name";
import defaultExport, { export [ , [...] ] } from "module-name";
import defaultExport, * as name from "module-name";
import "module-name";
var promise = import("module-name");
What I'm trying to understand is the difference between these two lines:
import { export1 , export2 } from "module-name";
import { foo , bar } from "module-name/path/to/specific/un-exported/file";
Wouldn't both of those be exactly the same? We're not importing a default export
, therefore we have to be importing named export
s.
Why are they two separate syntax definitions?
And why does the second one have this:
from "module-name/path/to/specific/un-exported/file";
Introduction to ES6 import:The import statement is used to import modules that are exported by some other module. A module is a file that contains a piece of reusable code. The import modules are in strict mode whether it is declared or not. Syntax of import: import name from 'module-name'
You can have multiple named exports per module but only one default export.
Combining. You can combine default and named exports in a single file. Importing is the same, named exports are in curly brackets, default is plaintext. React is a great example of a library that exports both default and named components.
Javascript import statement is used to import bindings that are exported by another module. Using import, the code is easier to manage when it is small and bite-size chunks. This is the thinking behind keeping functions to only one task or having files contain only a few or one component at a time.
import { export1 , export2 } from "module-name";
import { foo , bar } from "module-name/path/to/specific/un-exported/file";
Why are they two separate syntax definitions?
Probably just to illustrate the point that absolute module name can also contain a path.
Then, "module-name"
will be resolved according to usual module resolution rules, and then foo
and bar
will be imported from some file contained within that module.
That way, you can get access to something which is not exported from the main file of the module.
However, many module authors consider that only exports from the module main file constitute the public API. Everything else, including file names and paths, is an implementation detail which may change in unpredictable and incompatible way with each release.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With