Suppose several parts of an application need the same function. Making it global lets them call it, but also exposes its name to unrelated code. A module offers another route: put the function in a separate JavaScript file and export it for other files to import. section 20.2 section 3.2
A module is a file with its own scope and rules, not an object you can store in a variable. Its code can use local helpers without exporting them. Other modules receive only the values it explicitly exports, so files can share logic without relying on globals. section 20.0 section 20.2
Export a function, keep its helper private
In a statistics file, `function statsHelper() { /* process data */ }` can sit beside `export default function logStats(stat) { /* use statsHelper */ }`. The exported function can call the helper; an importing file receives the function, not the helper. A module can have only one default export, though it can also have named exports. section 20.2
Choose the interface that fits the file:
- Use a default export when one value is the file’s main offering; a default import may choose its local name. section 20.2 section 21.6
- Use named exports for additional values. Import them by their exported names, or rename them with `as`; `*` gathers named exports under one imported name. section 20.2 section 21.6
Listing 22.4. /src/status_display.js
The status-display file imports the named status functions as `status`, uses them to choose a message, and default-exports one function that returns HTML. Its message helper stays inside the file. section 22.4
Separate files also affect delivery. Transpiling module syntax alone does not assemble those files for the browser. Browserify follows imports from an entry file and bundles the required modules into one file; babelify can transpile each file before Browserify processes it. Try splitting a small interface into files whose exports expose only what another file needs. section 3.0 section 3.3 section 3.4 section 22.4
