Scope & lexical environments

Scope decides what names you can use

A name is the word you use for a variable, a constant, a parameter, or a function, like total. Scope is the part of a program where a name can be found.

Say you write console.log(total). Before JavaScript can print anything, it must answer one question. Which total can this line see? There might be several variables called total in your program, or none at all. Scope gives the answer.

This lesson covers:

• Global scope: names at the top level of a script.
• Function scope: names made inside a function.
• Block scope: names made inside a pair of braces, { }.
• The scope chain: how JavaScript searches outward, one scope at a time, to find a name.

You met some of this before. The Variables lesson showed that let stays inside its braces. The functions lesson showed a function reading a variable from outside it. Here you'll learn the full rule.

Lexical scope: where code is written

Lexical means "about the written text". In JavaScript, the place where you write a function decides which outside variables it can use. If you write a function inside another function, the inner one can use the outer one's variables.

The Closures lesson builds on this. A function can only remember outer variables that it can see. So first you need to know which outer variables a function can see.

Each function call has its own function scope. It holds the function's parameters and the variables made inside it.

function greet(user) {
  const message = "Hi, " + user;
  return message;
}

console.log(greet("Asha"));

Line 1 gives greet a parameter called user. Line 2 makes a constant called message. Both exist only while greet runs. Line 6 gets back the finished string, Hi, Asha. It can't use user or message.

An ES module is a JavaScript file that uses import and export. Each module has its own module scope. Names at the top of a module belong to that file only. Other files can use them only if the module exports them.

// profile.mjs
const user = "Asha";
export function getUser() {
  return user;
}

// app.mjs
import { getUser } from "./profile.mjs";
console.log(getUser());

This example is two files, so the page can't run it in one editor. In profile.mjs, line 2 makes user, and line 3 exports getUser. In app.mjs, line 9 calls getUser(), which prints Asha. The app never sees user itself. It is not a global name for the whole page.

Global scope is the outermost scope. A name written at the top level of a normal script, outside every function and block, is global. Code anywhere in that script can use it.

const siteName = "CompleteFrontend";

function showSite() {
  console.log(siteName);
}

showSite();

Line 1 makes siteName at the top level. Line 4 is inside showSite, and it can still read siteName. Line 7 calls the function, so it prints CompleteFrontend.

A global name can be read and changed by any code in the script. That makes mistakes easy, so keep globals few and make each one on purpose.

JavaScript also has a global object: one shared object that every script can reach. Its name is globalThis. It works in browsers and in Node.js.

const user = "Asha";
globalThis.cartCount = 3;

console.log(user);
console.log(globalThis.cartCount);

Line 1 makes a normal variable, user. Line 2 puts a property called cartCount on the global object. Line 4 prints Asha, and line 5 prints 3.

Sharing a value this way can help two scripts work together. But any other code can change it too, so a module that exports the value is usually safer.

A common mistake is giving a value to a name you never declared. To declare a name means to make it with let, const, or var. The line "use strict" turns on strict mode, a set of safer rules. In strict mode, giving a value to an undeclared name throws a ReferenceError.

function saveScore() {
  "use strict";
  const score = 10;
  console.log(score);
}

saveScore();

Line 2 turns on strict mode for saveScore. Line 3 declares score with const, so it belongs to saveScore only. Line 7 calls the function, and line 4 prints 10. Without the const, strict mode would throw a ReferenceError instead.

Calling a function doesn't give it your variables. In JavaScript, a function uses the variables from the place where it was written. Some other languages work differently. They use dynamic scope: the function uses the variables of whoever called it. JavaScript does not do that.

const label = "global";

function makeReader() {
  const label = "defined in makeReader";
  return function readLabel() {
    return label;
  };
}

const readLabel = makeReader();

function callFromAnotherPlace() {
  const label = "caller local";
  return readLabel();
}

console.log(callFromAnotherPlace());

Line 13 makes a label inside the caller, callFromAnotherPlace. But readLabel was written inside makeReader, on lines 5 to 7. So it reads the label from line 4. The playground also shows what dynamic scope would print. That line is only for comparison. JavaScript never prints it.

A block is code between braces, { }. It can be the body of an if, the body of a loop, or just a pair of braces on their own. Each block has its own block scope.

• let and const belong to the nearest block around them.
• The older var skips normal blocks. It belongs to the function around it, or to the whole script.

if (true) {
  let blockLet = "inside if";
  const blockConst = "inside if";
  var functionVar = "var ignores this block";
}

console.log(functionVar);
// console.log(blockLet); // ReferenceError outside the block

There are four kinds of scope. Read each row as: "this kind of scope is made by this, and it is good for this."

Give each variable the smallest scope it needs. If a value is only used inside an if or a for loop, declare it there. Don't declare it at the top of the whole function.

When JavaScript reads a name, it first looks in the current scope. If the name isn't there, it looks in the scope just outside. It keeps stepping outward, one scope at a time, until it finds the name. This path from the inside out is called the scope chain.

If the search reaches the global scope and still finds nothing, reading the name throws a ReferenceError.

1const room = "global lobby";Run2 3function outer() {4  const room = "outer hall";5  function inner() {6    // no local room here7    return room;8  }9  return inner();10}11 12console.log(outer());

Now pick the setting that adds const room = "inner desk" on line 6, and step through again. Only one line changed. But now inner has its own room, so the search stops right there and returns "inner desk". This is the main rule: the nearest name wins.

Shadowing happens when an inner scope makes a name that an outer scope already has. Inside the inner scope, the inner name hides the outer one. This is allowed, and sometimes useful. But it can also hide the value you meant to read.

Some same-name code is not allowed at all. JavaScript stops it before running anything, with a SyntaxError. Here, var skips the block, so it tries to make x in the same scope where let already made x.

let x = "outer";
{
  var x = "same function scope";
}

Here is shadowing that works:

let color = "blue";
{
  let color = "green";
  console.log(color);
}
console.log(color);

Line 1 makes color with the value blue. Line 3 makes a second color inside the block, with the value green. Line 4 is inside the block, so it prints green. Line 6 is after the closing brace. The inner color is gone, so line 6 prints blue. Shadowing hides the outer name for a while. It never changes it.

Lexical environment records

The specification is the official rule book for JavaScript. It describes each scope as a lexical environment record. A record has two parts:

• A list of the names in that scope, with their values.
• A link to the scope just outside it. The spec calls this the outer reference.

Each function call gets a record. Each block gets a record for its let and const names. Each module gets a record. The scope chain is just these outer links, followed one after another.

function makeGreeter(name) {
  const punctuation = "!";
  return function greet() {
    return "Hello, " + name + punctuation;
  };
}

const greetAda = makeGreeter("Ada");
console.log(greetAda());

Line 8 calls makeGreeter("Ada"). That call gets a record holding name and punctuation. Line 3 returns the greet function, which keeps a link to that record. So when line 9 calls it, line 4 can still read both names, and it prints Hello, Ada!. The next lesson, Closures, explains this fully.

Where you use this

Scope rules help you make everyday choices:

• Declare a value that only a loop uses inside that loop. Then later code can't use it by mistake.
• Keep helper functions in the same module as the data they read.
• Declare every name with let, const, or var, so you never make a global by accident.
• If an inner name hides an outer one and makes the code confusing, rename one of them.

const cart = { items: [] };

function addToCart(item) {
  const itemCount = cart.items.push(item);
  return itemCount;
}

console.log(addToCart("tea"));
console.log(cart.items);

Line 1 makes cart outside the function, so every call to addToCart adds to the same list. Line 4 makes itemCount inside the function. The array method push adds an item and gives back the new length. Each call gets a fresh itemCount, so it never becomes shared data. Line 8 prints 1, and line 9 prints ["tea"].

Common misconceptions

Key takeaways

• Lexical scope means a function uses the outer variables from where it is written.
• To find a name, JavaScript looks in the current scope first, then steps outward along the scope chain.
• let and const stay inside their block. var skips normal blocks.
• Shadowing means a nearer name hides an outer name with the same spelling. The outer one is unchanged.
• The spec describes each scope as an environment record: a list of names plus a link to the outer scope.

Up next: Closures, where a function keeps its outer variables after the outer function has finished.