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
+7-7Lines changed: 7 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -162,7 +162,7 @@ Mostly, the second approach is preferred, so that every "thing" resides in its o
162
162
163
163
Naturally, that requires a lot of files, as everything wants its own module, but that's not a problem at all. Actually, code navigation becomes easier if files are well-named and structured into folders.
164
164
165
-
Modules provide special `export default` ("the default export") syntax to make the "one thing per module" way look better.
165
+
Modules provide a special `export default` ("the default export") syntax to make the "one thing per module" way look better.
166
166
167
167
Put `export default` before the entity to export:
168
168
@@ -216,9 +216,9 @@ export default function(user) { // no function name
Not giving a name is fine, because `export default` is only one per file, so `import` without curly braces knows what to import.
219
+
Not giving a name is fine, because there is only one `export default` per file, so `import` without curly braces knows what to import.
220
220
221
-
Without `default`, such export would give an error:
221
+
Without `default`, such an export would give an error:
222
222
223
223
```js
224
224
export class { // Error! (non-default export needs a name)
@@ -241,7 +241,7 @@ function sayHi(user) {
241
241
export {sayHi as default};
242
242
```
243
243
244
-
Or, another situation, let's say a module`user.js`exports one main "default" thing and a few named ones (rarely the case, but happens):
244
+
Or, another situation, let's say a module`user.js`exports one main "default" thing, and a few named ones (rarely the case, but it happens):
245
245
246
246
```js
247
247
// 📁 user.js
@@ -277,9 +277,9 @@ new User('John');
277
277
278
278
### A word against default exports
279
279
280
-
Named exports are explicit. They exactly name what they import, so we have that information from them, that's a good thing.
280
+
Named exports are explicit. They exactly name what they import, so we have that information from them; that's a good thing.
281
281
282
-
Named exportsenforce us to use exactly the right name to import:
282
+
Named exportsforce us to use exactly the right name to import:
283
283
284
284
```js
285
285
import {User} from './user.js';
@@ -321,7 +321,7 @@ export {default as User} from './user.js'; // re-export default
321
321
322
322
Why would that be needed? Let's see a practical use case.
323
323
324
-
Imagine, we're writing a "package": a folder with a lot of modules, with some of the functionality exported outside (tools like NPM allow to publish and distribute such packages), and many modules are just "helpers", for the internal use in other package modules.
324
+
Imagine, we're writing a "package": a folder with a lot of modules, with some of the functionality exported outside (tools like NPM allow us to publish and distribute such packages), and many modules are just "helpers", for internal use in other package modules.
0 commit comments