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
In practice, there are mainly two kinds of modules.
157
157
158
-
1.Module that contains a library, pack of functions, like `say.js` above.
159
-
2.Module that declares a single entity, e.g. amodule`user.js`exports only `class User`.
158
+
1.Modules that contain a library, pack of functions, like `say.js` above.
159
+
2.Modules that declare a single entity, e.g. amodule`user.js`exports only `class User`.
160
160
161
161
Mostly, the second approach is preferred, so that every "thing" resides in its own module.
162
162
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.
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 "one thing per module" way look better.
165
+
Modules provide 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
@@ -291,7 +291,7 @@ import {User} from './user.js';
291
291
```js
292
292
import User from './user.js'; // works
293
293
import MyUser from './user.js'; // works too
294
-
// could be import Anything..., and it'll be work
294
+
// could be import Anything... and it'll still work
295
295
```
296
296
297
297
So team members may use different names to import the same thing, and that's not good.
export {default as User} from './user.js'; // re-export default
320
320
```
321
321
322
-
Why that may be needed? Let's see a practical use case.
322
+
Why would that be needed? Let's see a practical use case.
323
323
324
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.
325
325
@@ -389,17 +389,17 @@ export default class User {
389
389
390
390
1. `export User from './user.js'` won'twork. Whatcangowrong?... Butthat's a syntax error!
391
391
392
-
To re-export the default export, we should write `export {default as User}`, as in the example above.
392
+
To re-export the default export, we have to write `export {default as User}`, as in the example above.
393
393
394
-
2. `export * from './user.js'` re-exports only named exports, ignores the default one.
394
+
2. `export * from './user.js'` re-exports only named exports, but ignores the default one.
395
395
396
396
If we'dliketore-exportbothnamedandthedefaultexport, thentwostatementsareneeded:
397
397
```js
398
398
export * from './user.js'; // to re-export named exports
399
399
export {default} from './user.js'; // to re-export the default export
400
400
```
401
401
402
-
Such oddities of re-exporting the default exportisoneofthereasons,whysomedevelopersdon't like them.
402
+
Such oddities of re-exporting the default exportareoneofthereasonswhysomedevelopersdon't like them.
0 commit comments