minor fixes

This commit is contained in:
Ilya Kantor 2021-05-24 11:55:27 +03:00
parent 842f0e22a6
commit 70bb2653e5

View file

@ -188,9 +188,13 @@ That's exactly because the module is executed only once. Exports are generated,
In other words, a module can provide a generic functionality that needs a setup. E.g. authentication needs credentials. Then it can export a configuration object expecting the outer code to assign to it.
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.
Here's a classical pattern:
1. A module exports some means of configuration, e.g. a configuration object.
2. On the first import we initialize it, write to its properties. The top-level application script may do that.
3. Further imports use the module.
For instance, the `admin.js` module may provide certain functionality, but expect the credentials to come into the `config` object from outside:
First, we can export the `config` object (here it's initially empty, but that's not always the case):
```js
// 📁 admin.js
export let config = { };
@ -200,6 +204,8 @@ export function sayHi() {
}
```
Here, `admin.js` exports the `config` object (initially empty, but that's not always the case).
Then in `init.js`, the first script of our app, we set `config.user`:
```js
@ -208,7 +214,9 @@ import {config} from './admin.js';
config.user = "Pete";
```
...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):
...Now the module is configured.
Further importers can call it, and it correctly shows the current user:
```js
// 📁 another.js
@ -217,10 +225,6 @@ import {sayHi} from './admin.js';
sayHi(); // Ready to serve, *!*Pete*/!*!
```
Here's a classical pattern:
1. A module exports some means of configuration.
2. On the first import we initialize it.
3. Further imports use the module.
### import.meta