You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 1-js/13-modules/02-import-export/article.md
+13-24Lines changed: 13 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ Also, we can put `export` separately.
46
46
47
47
Here we first declare, and then export:
48
48
49
-
```js
49
+
```js
50
50
// π say.js
51
51
functionsayHi(user) {
52
52
alert(`Hello, ${user}!`);
@@ -93,25 +93,14 @@ At first sight, "import everything" seems such a cool thing, short to write, why
93
93
94
94
Well, there are few reasons.
95
95
96
-
1. Modern build tools ([webpack](https://webpack.js.org/) and others) bundle modules together and optimize them to speedup loading and remove unused stuff.
97
-
98
-
Let's say, we added a 3rd-party library `say.js` to our project with many functions:
99
-
```js
100
-
// π say.js
101
-
exportfunctionsayHi() { ... }
102
-
exportfunctionsayBye() { ... }
103
-
exportfunctionbecomeSilent() { ... }
104
-
```
96
+
1. Explicitly listing what to import gives shorter names: `sayHi()` instead of `say.sayHi()`.
97
+
2. Explicit list of imports gives better overview of the code structure: what is used and where. It makes code support and refactoring easier.
105
98
106
-
Now if we only use one of`say.js` functions in our project:
107
-
```js
108
-
// π main.js
109
-
import {sayHi} from './say.js';
110
-
```
111
-
...Then the optimizer will see that and remove the other functions from the bundled code, thus making the build smaller. That is called "tree-shaking".
99
+
```smart header="Don't be afraid to import too much"
100
+
Modern build tools, such as [webpack](https://webpack.js.org/) and others, bundle modules together and optimize them to speedup loading. They also removed unused imports.
112
101
113
-
2. Explicitly listing what to importgives shorter names: `sayHi()` instead of `say.sayHi()`.
114
-
3. Explicit list of imports gives better overview of the code structure: what is used and where. It makes code support and refactoring easier.
102
+
For instance, if you `import * as library` from a huge code library, and then use only few methods, then unused ones [will not be included](https://github.com/webpack/webpack/tree/main/examples/harmony-unused#examplejs) into the optimzed bundle.
103
+
```
115
104
116
105
## Import "as"
117
106
@@ -224,7 +213,7 @@ Without `default`, such an export would give an error:
224
213
exportclass { // Error! (non-default export needs a name)
225
214
constructor() {}
226
215
}
227
-
```
216
+
```
228
217
229
218
### The "default" name
230
219
@@ -326,7 +315,7 @@ Imagine, we're writing a "package": a folder with a lot of modules, with some of
326
315
The file structure could be like this:
327
316
```
328
317
auth/
329
-
index.js
318
+
index.js
330
319
user.js
331
320
helpers.js
332
321
tests/
@@ -372,15 +361,15 @@ The syntax `export ... from ...` is just a shorter notation for such import-expo
372
361
373
362
```js
374
363
// π auth/index.js
375
-
// re-export login/logout
364
+
// re-export login/logout
376
365
export {login, logout} from'./helpers.js';
377
366
378
367
// re-export the default export as User
379
368
export {defaultasUser} from'./user.js';
380
369
...
381
370
```
382
371
383
-
The notable difference of `export ... from` compared to `import/export` is that re-exported modules aren't available in the current file. So inside the above example of `auth/index.js` we can't use re-exported `login/logout` functions.
372
+
The notable difference of `export ... from` compared to `import/export` is that re-exported modules aren't available in the current file. So inside the above example of `auth/index.js` we can't use re-exported `login/logout` functions.
384
373
385
374
### Re-exporting the default export
386
375
@@ -399,7 +388,7 @@ We can come across two problems with it:
399
388
400
389
1.`export User from './user.js'` won't work. That would lead to a syntax error.
401
390
402
-
To re-export the default export, we have to write `export {default as User}`, as in the example above.
391
+
To re-export the default export, we have to write `export {default as User}`, as in the example above.
403
392
404
393
2.`export * from './user.js'` re-exports only named exports, but ignores the default one.
0 commit comments