Skip to content

Commit 7b47d37

Browse files
authored
Update article.md
Grammar suggestions
1 parent dcb9d87 commit 7b47d37

File tree

1 file changed

+9
-9
lines changed

1 file changed

+9
-9
lines changed

1-js/13-modules/02-import-export/article.md

+9-9
Original file line numberDiff line numberDiff line change
@@ -155,14 +155,14 @@ say.*!*bye*/!*('John'); // Bye, John!
155155

156156
In practice, there are mainly two kinds of modules.
157157

158-
1. Module that contains a library, pack of functions, like `say.js` above.
159-
2. Module that declares a single entity, e.g. a module `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. a module `user.js` exports only `class User`.
160160

161161
Mostly, the second approach is preferred, so that every "thing" resides in its own module.
162162

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.
164164
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.
166166
167167
Put `export default` before the entity to export:
168168
@@ -291,7 +291,7 @@ import {User} from './user.js';
291291
```js
292292
import User from './user.js'; // works
293293
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
295295
```
296296

297297
So team members may use different names to import the same thing, and that's not good.
@@ -319,7 +319,7 @@ export {sayHi} from './say.js'; // re-export sayHi
319319
export {default as User} from './user.js'; // re-export default
320320
```
321321
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.
323323

324324
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.
325325
@@ -389,17 +389,17 @@ export default class User {
389389
390390
1. `export User from './user.js'` won't work. What can go wrong?... But that's a syntax error!
391391
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.
393393
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.
395395
396396
If we'd like to re-export both named and the default export, then two statements are needed:
397397
```js
398398
export * from './user.js'; // to re-export named exports
399399
export {default} from './user.js'; // to re-export the default export
400400
```
401401

402-
Such oddities of re-exporting the default export is one of the reasons, why some developers don't like them.
402+
Such oddities of re-exporting the default export are one of the reasons why some developers don't like them.
403403
404404
## Summary
405405

0 commit comments

Comments
 (0)