Skip to content

Commit 4343545

Browse files
committed
minor fixes
1 parent 6db4961 commit 4343545

File tree

1 file changed

+17
-13
lines changed

1 file changed

+17
-13
lines changed

1-js/13-modules/01-modules-intro/article.md

+17-13
Original file line numberDiff line numberDiff line change
@@ -184,40 +184,44 @@ As you can see, when `1.js` changes the `name` property in the imported `admin`,
184184

185185
That's exactly because the module is executed only once. Exports are generated, and then they are shared between importers, so if something changes the `admin` object, other modules will see that.
186186

187-
**Such behavior is actually very convenient, because it allows us to *configure* modules on first import.**
187+
**Such behavior is actually very convenient, because it allows us to *configure* modules.**
188188

189-
In other words, when the module code is evaluated (happens only the first time!), we can setup its properties once. And then in further imports it's ready.
189+
In other words, we can create variables with configuration and export them, so that the outer code can modify them.
190190

191-
For instance, the `admin.js` module may provide certain functionality, but expect the credentials to come into the `admin` object from outside:
191+
For instance, the `admin.js` module may provide certain functionality (e.g. authentication), but expect the credentials to come into the `config` object from outside.
192192

193+
First, we can export the `config` object (here it's initially empty, but that's not always the case):
193194
```js
194195
// 📁 admin.js
195-
export let admin = { };
196+
export let config = { };
196197

197198
export function sayHi() {
198-
alert(`Ready to serve, ${admin.name}!`);
199+
alert(`Ready to serve, ${config.user}!`);
199200
}
200201
```
201202

202-
In `init.js`, the first script of our app, we set `admin.name`. Then everyone will see it, including calls made from inside `admin.js` itself:
203+
Then in `init.js`, the first script of our app, we set `config.user`:
203204

204205
```js
205206
// 📁 init.js
206-
import {admin} from './admin.js';
207-
admin.name = "Pete";
207+
import {config} from './admin.js';
208+
config.user = "Pete";
208209
```
209210

210-
Another module can also see `admin.name`:
211+
...Now the module is configured. It's `config` property has the right user, and it can say hi to them (or provide authentication or whatever):
211212

212213
```js
213-
// 📁 other.js
214-
import {admin, sayHi} from './admin.js';
215-
216-
alert(admin.name); // *!*Pete*/!*
214+
// 📁 another.js
215+
import {sayHi} from './admin.js';
217216

218217
sayHi(); // Ready to serve, *!*Pete*/!*!
219218
```
220219

220+
Here's a classical pattern:
221+
1. A module exports some means of configuration.
222+
2. On the first import we initialize it.
223+
3. Further imports use the module.
224+
221225
### import.meta
222226

223227
The object `import.meta` contains the information about the current module.

0 commit comments

Comments
 (0)