Scope, closures, and modules

Why this matters

Every file you have written so far has been one file, and every name in it was visible to every other line. That stops working around a hundred lines, when two parts of the program accidentally share a name and quietly overwrite each other.

Today you learn the two tools that fix it: scope, which controls where a name is visible, and modules, which split code across files and share only what you choose. By the end of the hour your inventory project is four files that import from each other, with nothing leaking into the global space.

Block scope and function scope

A scope is a region of code in which a name exists. Ask "can this line see that name?" and the answer is decided by scope, not by what looks nearby on screen.

let and const are block-scoped. A block is any pair of braces { } — the body of an if, a loop, or a function. A name declared inside a block does not exist outside it.

if (true) {
  let inner = "block only";
  console.log(inner);
}
console.log(inner);

block only
ReferenceError: inner is not defined

That error is not a failure; it is the guarantee working. inner was never meant to escape.

Functions create a scope too, and they can see outward. A function body can read names from the scope that surrounds it, and from the scope surrounding that, all the way up. The reverse is never true: the outside cannot see in.

const threshold = 10;

function isLowStock(item) {
  const label = item.name;          // visible only inside this function
  return item.quantity < threshold; // reads outward, and that is allowed
}

console.log(isLowStock({ name: "NE555", quantity: 3 })); // true
console.log(label);                                      // ReferenceError: label is not defined

The old var declaration you were warned off on Day 15 is function-scoped, not block-scoped: a var inside an if leaks to the whole enclosing function. That mismatch is why let and const exist. Keep using them.

Closures, practically

When you return a function from another function, the returned function keeps access to the scope it was born in — even after the outer function has finished. That combination of a function plus the surrounding variables it remembers is a closure.

function makeCounter(startAt) {
  let count = startAt;
  return function next() {
    count = count + 1;
    return count;
  };
}

const ticket = makeCounter(0);
console.log(ticket()); // 1
console.log(ticket()); // 2

const other = makeCounter(100);
console.log(other());  // 101
console.log(ticket()); // 3

Two facts to take from that output. First, count survives between calls — ticket() returns 1, then 2, then 3 — even though makeCounter returned long ago. Second, other has its own count: each call to makeCounter creates a fresh scope. And count itself is unreachable from outside; the only way to change it is through the function that was given the key.

The everyday use is making configured functions. Day 22's array methods take a callback, so a closure is the tidy way to build one with a setting baked in:

function makeLowStockCheck(threshold) {
  return (item) => item.quantity < threshold;
}

const isCritical = makeLowStockCheck(5);
const components = [{ id: "R1", quantity: 42 }, { id: "U1", quantity: 3 }];
console.log(components.filter(isCritical)); // [ { id: 'U1', quantity: 3 } ]

Modules: export and import

A module is one file treated as a unit of code. Modules help with organizing code into explicit units and sharing only what each unit chooses to share. Two things follow. Everything declared at the top of a module file is private to that file by default — it is not a global. And anything you mark with export becomes available to other files that import it.

// calc.js
export function totalValue(items) {
  return items.reduce((sum, item) => sum + item.quantity * item.unitPrice, 0);
}

export function lowStock(items, threshold) {
  return items.filter((item) => item.quantity < threshold);
}

// main.js
import { components } from "./data.js";
import { totalValue, lowStock } from "./calc.js";

Three rules the browser enforces, and each one is a common first-time failure:

• The path needs a ./ (or ../) prefix and the .js extension. import ... from "calc.js" fails in a browser; "./calc.js" works.
• The names in the braces must match the exported names exactly, including case.
• import lines go at the top of the file. They are resolved before any of your code runs.

The names in braces are named exports. A file may also have one export default, imported without braces as import anyName from "./calc.js". Named exports are clearer — the name in the import matches the name in the source — so use those.

Walkthrough

Build the four-file project. In ~/fullstack-journey/inventory-app, create data.js, calc.js, render.js, main.js, and index.html.

// data.js
export const components = [
  { id: "R1", name: "Resistor 10k",    category: "resistor",  quantity: 42, unitPrice: 0.02 },
  { id: "C1", name: "Capacitor 100nF", category: "capacitor", quantity: 8,  unitPrice: 0.05 },
  { id: "U1", name: "NE555 timer",     category: "ic",        quantity: 3,  unitPrice: 0.45 },
];

// render.js
export function formatLine(item) {
  return `${item.id} ${item.name} — ${item.quantity} left`;
}

Put the calc.js from above in place, then wire it together:

// main.js
import { components } from "./data.js";
import { totalValue, lowStock } from "./calc.js";
import { formatLine } from "./render.js";

console.log("Total value:", totalValue(components).toFixed(2));
console.log(lowStock(components, 10).map(formatLine).join("\n"));

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Inventory</title>
  </head>
  <body>
    <h1>Inventory</h1>
    <script type="module" src="./main.js"></script>
  </body>
</html>

type="module" is what makes import legal in the browser. You load only main.js; the browser follows its imports and fetches the rest itself.

cd ~/fullstack-journey/inventory-app
npx serve

Total value: 2.59
C1 Capacitor 100nF — 8 left
U1 NE555 timer — 3 left

Your turn

Build a browser project with working module imports and no global variables.

1. Get the four files above running and confirm the three lines appear in the Console.
2. Move your Day 21 calculator functions (series resistance, parallel resistance, wattage) into a new calc-resistors.js, one export function each. Import and call them from main.js.
3. Add a categoryTotal(items, category) to calc.js using filter and reduce from Day 22. Export it, import it, and print one category total.
4. In render.js, add formatReport(title, lines) that returns a heading plus the lines joined by newlines. Keep every console.log in main.js — render.js returns strings, it does not print.
5. Deliberately break one import: change "./calc.js" to "calc.js". Read the console error, then fix it. Break a name next: import { totalvalue }. Read that error too, then fix it.
6. Prove the isolation. In the Console, type the name of any function you defined. Each should report is not defined.

Common pitfalls

• Opening the HTML from the filesystem. Modules need http://. If nothing runs and the console mentions CORS or origin 'null', you skipped npx serve.
• Forgetting type="module". A plain <script src="./main.js"> gives SyntaxError: Cannot use import statement outside a module.
• Exporting nothing and wondering why the import is empty. export must be on the declaration you want shared. No export, no counter, no access.
• Declaring the same name in two scopes and expecting the inner one to update the outer. It does not — the inner declaration is a separate variable that shadows the outer one for that block.

Verify it yourself

Open today's reference, MDN's Dynamic scripting with JavaScript, and find its pages on function scope, closures, and JavaScript modules.

1. MDN states that module code runs in strict mode automatically, and that modules are deferred until the page is parsed. Find both statements and write down one consequence of each.
2. This lesson recommended named exports over export default. Find MDN's description of default exports and write one sentence on when a default might actually be the better choice.

Add both answers as comments at the top of main.js. Reading the specification for the rule behind a habit is how the habit becomes a decision.