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/01-modules-intro/article.md
+17-13
Original file line number
Diff line number
Diff line change
@@ -184,40 +184,44 @@ As you can see, when `1.js` changes the `name` property in the imported `admin`,
184
184
185
185
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.
186
186
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.**
188
188
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.
190
190
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.
192
192
193
+
First, we can export the `config` object (here it's initially empty, but that's not always the case):
193
194
```js
194
195
// 📁 admin.js
195
-
exportletadmin= { };
196
+
exportletconfig= { };
196
197
197
198
exportfunctionsayHi() {
198
-
alert(`Ready to serve, ${admin.name}!`);
199
+
alert(`Ready to serve, ${config.user}!`);
199
200
}
200
201
```
201
202
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`:
203
204
204
205
```js
205
206
// 📁 init.js
206
-
import {admin} from'./admin.js';
207
-
admin.name="Pete";
207
+
import {config} from'./admin.js';
208
+
config.user="Pete";
208
209
```
209
210
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):
211
212
212
213
```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';
217
216
218
217
sayHi(); // Ready to serve, *!*Pete*/!*!
219
218
```
220
219
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
+
221
225
### import.meta
222
226
223
227
The object `import.meta` contains the information about the current module.
0 commit comments