Every expense in Pocket needs a unique id so you can edit or delete exactly that one later. The obvious approach is a counter at the top of the file:
\nlet nextId = 1;\nfunction createId() {\n return `exp-${nextId++}`;\n}It works, until some other part of the program, perhaps a “reset” feature written months later, sets nextId = 1 again and you get two expenses called exp-1. The counter is visible everywhere, so anything can break it. To protect it you need to understand scope: the rules for where a name can be seen.
Every pair of curly braces creates a block, and let and const names live in the block where they are declared. Functions create a scope too. Names declared outside every block and function are in the global scope, visible everywhere.
const appName = \"Pocket\"; // global\n\nfunction describe(amount) {\n const size = amount > 10000 ? \"big\" : \"small\"; // function scope\n if (size === \"big\") {\n const warning = \"Think twice\"; // block scope\n console.log(appName, size, warning);\n }\n // console.log(warning) here would throw a ReferenceError\n}\n\ndescribe(12000);When the engine meets a name, it looks in the current scope first. If the name is not there, it looks in the enclosing scope, then the one around that, out to the global scope. If it still has not found it, you get ReferenceError: … is not defined. The lookup only goes outward: code inside a function can read the global appName, but code outside the function can never see size.
That is why the warning line is commented out. The block that declared warning has ended, so the name is gone.
If an inner scope declares a name that already exists outside, the inner one shadows the outer one: inside the block, the name means the inner variable. It is legal, but two different things with one name make code hard to read, so pick distinct names.
\nBefore 2015, JavaScript only had var, and var ignores blocks: it is visible throughout the whole function it is in. That produces one famous bug. Here the loop schedules three functions to run a moment later with setTimeout:
for (var i = 0; i < 3; i++) {\n setTimeout(() => console.log(\"var:\", i), 0);\n}\nfor (let j = 0; j < 3; j++) {\n setTimeout(() => console.log(\"let:\", j), 0);\n}The var loop logs 3 three times, because there is only one i for the whole loop, and by the time the functions run it has reached 3. The let loop logs 0, 1 and 2, because let creates a fresh j for each pass and each function keeps its own. Those functions remembering variables is exactly what a closure is.
A function created inside another function can use the outer function’s variables. The surprise is that it keeps that access after the outer function has returned:
\nfunction createIdGenerator(prefix) {\n let count = 0;\n return () => {\n count++;\n return `${prefix}-${count}`;\n };\n}\n\nconst nextExpenseId = createIdGenerator(\"exp\");\nconst nextCategoryId = createIdGenerator(\"cat\");\n\nconsole.log(nextExpenseId());\nconsole.log(nextExpenseId());\nconsole.log(nextCategoryId());\nconsole.log(nextExpenseId());Follow the engine. Calling createIdGenerator("exp") creates a fresh prefix and count, builds the arrow function, and returns it. Normally a function’s variables vanish when it returns, but the arrow function still refers to count and prefix, so they stay alive, attached to it. That pairing of a function with the variables it was born next to is a closure.
Each call of createIdGenerator creates a new, separate set of variables. That is why nextCategoryId() starts from 1 and the expense ids carry on from where they were.
Now look at the safety you gained. There is no global count. No other code can read it, reset it or set it to a duplicate value. The only way to affect it is to call the function you were given, which can only ever move it forward. This is the standard way to give a function private state in JavaScript.
A closure can protect more than a counter. Here is a budget that can only go down through the function you hand out:
\nfunction createBudget(limitCents) {\n let remaining = limitCents;\n return (spentCents) => {\n remaining -= spentCents;\n return remaining;\n };\n}\n\nconst spend = createBudget(2000);\nconsole.log(spend(450));\nconsole.log(spend(1220));Section 2 is complete: you can make decisions, repeat work, and package it in functions with their own private state. Section 3 turns to data, starting with the list you have been looping over: the array.
\n","toc":[{"id":"sec-1","text":"Blocks, functions and the global scope","level":2},{"id":"sec-2","text":"The trouble with var","level":2},{"id":"sec-3","text":"Closures: functions that remember","level":2}],"takeaways":["Scope is where a name can be used:let and const live in the nearest block { }, and lookups go outward, never inward.","An inner name with the same name as an outer one shadows it inside the inner scope, which is legal but easy to misread.","var ignores blocks and is scoped to the whole function, which causes classic bugs; use let and const.","A closure is a function that keeps access to the variables of the scope where it was created, even after that outer function has returned.","Each call of an outer function creates a fresh set of variables, so every closure it returns has its own private state."],"further":[{"title":"Closures (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Closures"},{"title":"Scope (MDN glossary)","url":"https://developer.mozilla.org/en-US/docs/Glossary/Scope"},{"title":"var (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var"}],"quiz":[{"q":"What happens when this runs?
\nfunction check(amount) {\n if (amount > 100) {\n const label = \"big\";\n }\n return label;\n}\nconsole.log(check(500));big.","why":"label was declared with const inside the if block, so it does not exist outside those braces."},{"text":"It logs undefined.","why":"undefined is what var gives when the if is skipped, as in check(50); with var and 500 you would even get big. With const, the name does not exist outside its block, so using it there is an error."},{"text":"It throws ReferenceError: label is not defined.","why":"Correct. Block scope means label disappears at the closing brace of the if, and return label cannot see it."}],"answer":2},{"q":"What does this log?
\nfunction makeCounter() {\n let count = 0;\n return () => {\n count++;\n return count;\n };\n}\nconst a = makeCounter();\nconst b = makeCounter();\na(); a();\nconsole.log(a(), b());3 1","why":"Correct. Each call of makeCounter creates its own count. a has been called three times, b once."},{"text":"3 4","why":"That would need one shared count. Every call of makeCounter creates a separate one."},{"text":"1 1","why":"count is not reset on each call of the inner function; the closure keeps the same variable alive between calls."},{"text":"0 0","why":"Each call of the returned function runs count++ before returning, so the first call already returns 1."}],"answer":0},{"q":"Why is a closure-based id generator safer than a global let nextId = 1?
The starter’s id generator shares one global count, so two generators interfere and any code can reset it. Rewrite createIdGenerator(prefix) so each generator has its own private counter and there is no global count any more: a new generator’s first id is always prefix-1.
Then write createBudget(limitCents), which returns a function spend(cents). Each call subtracts cents from a private remaining amount (starting at limitCents) and returns what is left. It may go negative.
createIdGenerator are created fresh on every call. Move let count = 0; there and delete the global one.","createBudget has the same shape: declare let remaining = limitCents;, then return (cents) => { … };.","Inside the returned function: remaining -= cents; return remaining;."],"explanation":"Declaring count inside createIdGenerator means every call creates a new variable, and the arrow function returned from that call closes over its own copy. That is why two generators no longer interfere and why the first id is always 1. With the global gone, nothing outside the closure can touch the counter. createBudget uses the same pattern: remaining survives between calls to spend because the returned function still refers to it, yet no other code can read or change it except through spend.
count variable any more","budget":"spend subtracts and returns what is left","budget-independent":"Two budgets keep separate remaining amounts"}},"words":739,"readMinutes":4}