let and const are two relatively new types of variable declarations in JavaScript.\nAs we mentioned earlier, let is similar to var in some respects, but allows users to avoid some of the common “gotchas” that users run into in JavaScript.\nconst is an augmentation of let in that it prevents re-assignment to a variable.
With TypeScript being an extension of JavaScript, the language naturally supports let and const.\nHere we’ll elaborate more on these new declarations and why they’re preferable to var.
If you’ve used JavaScript offhandedly, the next section might be a good way to refresh your memory.\nIf you’re intimately familiar with all the quirks of var declarations in JavaScript, you might find it easier to skip ahead.
var declarationsDeclaring a variable in JavaScript has always traditionally been done with the var keyword.
\ntsvar a = 10;
As you might’ve figured out, we just declared a variable named a with the value 10.
We can also declare a variable inside of a function:
\n\ntsfunction f() {\n var message = \"Hello, world!\";\n\n return message;\n}
and we can also access those same variables within other functions:
\n\ntsfunction f() {\n var a = 10;\n return function g() {\n var b = a + 1;\n return b;\n };\n}\n\nvar g = f();\ng(); // returns '11'
In this above example, g captured the variable a declared in f.\nAt any point that g gets called, the value of a will be tied to the value of a in f.\nEven if g is called once f is done running, it will be able to access and modify a.
\ntsfunction f() {\n var a = 1;\n\n a = 2;\n var b = g();\n a = 3;\n\n return b;\n\n function g() {\n return a;\n }\n}\n\nf(); // returns '2'
var declarations have some odd scoping rules for those used to other languages.\nTake the following example:
\ntsfunction f(shouldInitialize: boolean) {\n if (shouldInitialize) {\n var x = 10;\n }\n\n return x;\n}\n\nf(true); // returns '10'\nf(false); // returns 'undefined'
Some readers might do a double-take at this example.\nThe variable x was declared within the if block, and yet we were able to access it from outside that block.\nThat’s because var declarations are accessible anywhere within their containing function, module, namespace, or global scope - all which we’ll go over later on - regardless of the containing block.\nSome people call this var-scoping or function-scoping.\nParameters are also function scoped.
These scoping rules can cause several types of mistakes.\nOne problem they exacerbate is the fact that it is not an error to declare the same variable multiple times:
\n\ntsfunction sumMatrix(matrix: number[][]) {\n var sum = 0;\n for (var i = 0; i < matrix.length; i++) {\n var currentRow = matrix[i];\n for (var i = 0; i < currentRow.length; i++) {\n sum += currentRow[i];\n }\n }\n\n return sum;\n}
Maybe it was easy to spot out for some experienced JavaScript developers, but the inner for-loop will accidentally overwrite the variable i because i refers to the same function-scoped variable.\nAs experienced developers know by now, similar sorts of bugs slip through code reviews and can be an endless source of frustration.
Take a quick second to guess what the output of the following snippet is:
\n\ntsfor (var i = 0; i < 10; i++) {\n setTimeout(function() {\n console.log(i);\n }, 100 * i);\n}
For those unfamiliar, setTimeout will try to execute a function after a certain number of milliseconds (though waiting for anything else to stop running).
Ready? Take a look:
\n10\n10\n10\n10\n10\n10\n10\n10\n10\n10\nMany JavaScript developers are intimately familiar with this behavior, but if you’re surprised, you’re certainly not alone.\nMost people expect the output to be
\n0\n1\n2\n3\n4\n5\n6\n7\n8\n9\nRemember what we mentioned earlier about variable capturing?\nEvery function expression we pass to setTimeout actually refers to the same i from the same scope.
Let’s take a minute to consider what that means.\nsetTimeout will run a function after some number of milliseconds, but only after the for loop has stopped executing;\nBy the time the for loop has stopped executing, the value of i is 10.\nSo each time the given function gets called, it will print out 10!
A common work around is to use an IIFE - an Immediately Invoked Function Expression - to capture i at each iteration:
\ntsfor (var i = 0; i < 10; i++) {\n // capture the current state of 'i'\n // by invoking a function with its current value\n (function(i) {\n setTimeout(function() {\n console.log(i);\n }, 100 * i);\n })(i);\n}
This odd-looking pattern is actually pretty common.\nThe i in the parameter list actually shadows the i declared in the for loop, but since we named them the same, we didn’t have to modify the loop body too much.
let declarationsBy now you’ve figured out that var has some problems, which is precisely why let statements were introduced.\nApart from the keyword used, let statements are written the same way var statements are.
\ntslet hello = \"Hello!\";
The key difference is not in the syntax, but in the semantics, which we’ll now dive into.
\nWhen a variable is declared using let, it uses what some call lexical-scoping or block-scoping.\nUnlike variables declared with var whose scopes leak out to their containing function, block-scoped variables are not visible outside of their nearest containing block or for-loop.
\ntsfunction f(input: boolean) {\n let a = 100;\n\n if (input) {\n // Still okay to reference 'a'\n let b = a + 1;\n return b;\n }\n\n // Error: 'b' doesn't exist here\n return b;\n}
Here, we have two local variables a and b.\na’s scope is limited to the body of f while b’s scope is limited to the containing if statement’s block.
Variables declared in a catch clause also have similar scoping rules.
\ntstry {\n throw \"oh no!\";\n} catch (e) {\n console.log(\"Oh well.\");\n}\n\n// Error: 'e' doesn't exist here\nconsole.log(e);
Another property of block-scoped variables is that they can’t be read or written to before they’re actually declared.\nWhile these variables are “present” throughout their scope, all points up until their declaration are part of their temporal dead zone.\nThis is just a sophisticated way of saying you can’t access them before the let statement, and luckily TypeScript will let you know that.
\ntsa++; // illegal to use 'a' before it's declared;\nlet a;
Something to note is that you can still capture a block-scoped variable before it’s declared.\nThe only catch is that it’s illegal to call that function before the declaration.\nIf targeting ES2015, a modern runtime will throw an error; however, right now TypeScript is permissive and won’t report this as an error.
\n\ntsfunction foo() {\n // okay to capture 'a'\n return a;\n}\n\n// illegal call 'foo' before 'a' is declared\n// runtimes should throw an error here\nfoo();\n\nlet a;
For more information on temporal dead zones, see relevant content on the Mozilla Developer Network.
\nWith var declarations, we mentioned that it didn’t matter how many times you declared your variables; you just got one.
\ntsfunction f(x) {\n var x;\n var x;\n\n if (true) {\n var x;\n }\n}
In the above example, all declarations of x actually refer to the same x, and this is perfectly valid.\nThis often ends up being a source of bugs.\nThankfully, let declarations are not as forgiving.
\ntslet x = 10;\nlet x = 20; // error: can't re-declare 'x' in the same scope
The variables don’t necessarily need to both be block-scoped for TypeScript to tell us that there’s a problem.
\n\ntsfunction f(x) {\n let x = 100; // error: interferes with parameter declaration\n}\n\nfunction g() {\n let x = 100;\n var x = 100; // error: can't have both declarations of 'x'\n}
That’s not to say that a block-scoped variable can never be declared with a function-scoped variable.\nThe block-scoped variable just needs to be declared within a distinctly different block.
\n\ntsfunction f(condition, x) {\n if (condition) {\n let x = 100;\n return x;\n }\n\n return x;\n}\n\nf(false, 0); // returns '0'\nf(true, 0); // returns '100'
The act of introducing a new name in a more nested scope is called shadowing.\nIt is a bit of a double-edged sword in that it can introduce certain bugs on its own in the event of accidental shadowing, while also preventing certain bugs.\nFor instance, imagine we had written our earlier sumMatrix function using let variables.
\ntsfunction sumMatrix(matrix: number[][]) {\n let sum = 0;\n for (let i = 0; i < matrix.length; i++) {\n var currentRow = matrix[i];\n for (let i = 0; i < currentRow.length; i++) {\n sum += currentRow[i];\n }\n }\n\n return sum;\n}
This version of the loop will actually perform the summation correctly because the inner loop’s i shadows i from the outer loop.
Shadowing should usually be avoided in the interest of writing clearer code.\nWhile there are some scenarios where it may be fitting to take advantage of it, you should use your best judgement.
\nWhen we first touched on the idea of variable capturing with var declaration, we briefly went into how variables act once captured.\nTo give a better intuition of this, each time a scope is run, it creates an “environment” of variables.\nThat environment and its captured variables can exist even after everything within its scope has finished executing.
\ntsfunction theCityThatAlwaysSleeps() {\n let getCity;\n\n if (true) {\n let city = \"Seattle\";\n getCity = function() {\n return city;\n };\n }\n\n return getCity();\n}
Because we’ve captured city from within its environment, we’re still able to access it despite the fact that the if block finished executing.
Recall that with our earlier setTimeout example, we ended up needing to use an IIFE to capture the state of a variable for every iteration of the for loop.\nIn effect, what we were doing was creating a new variable environment for our captured variables.\nThat was a bit of a pain, but luckily, you’ll never have to do that again in TypeScript.
let declarations have drastically different behavior when declared as part of a loop.\nRather than just introducing a new environment to the loop itself, these declarations sort of create a new scope per iteration.\nSince this is what we were doing anyway with our IIFE, we can change our old setTimeout example to just use a let declaration.
\ntsfor (let i = 0; i < 10; i++) {\n setTimeout(function() {\n console.log(i);\n }, 100 * i);\n}
and as expected, this will print out
\n0\n1\n2\n3\n4\n5\n6\n7\n8\n9\nconst declarationsconst declarations are another way of declaring variables.
\ntsconst numLivesForCat = 9;
They are like let declarations but, as their name implies, their value cannot be changed once they are bound.\nIn other words, they have the same scoping rules as let, but you can’t re-assign to them.
This should not be confused with the idea that the values they refer to are immutable.
\n\ntsconst numLivesForCat = 9;\nconst kitty = {\n name: \"Aurora\",\n numLives: numLivesForCat\n};\n\n// Error\nkitty = {\n name: \"Danielle\",\n numLives: numLivesForCat\n};\n\n// all \"okay\"\nkitty.name = \"Rory\";\nkitty.name = \"Kitty\";\nkitty.name = \"Cat\";\nkitty.numLives--;
Unless you take specific measures to avoid it, the internal state of a const variable is still modifiable.\nFortunately, TypeScript allows you to specify that members of an object are readonly.\nThe chapter on Interfaces has the details.
let vs. constGiven that we have two types of declarations with similar scoping semantics, it’s natural to find ourselves asking which one to use.\nLike most broad questions, the answer is: it depends.
\nApplying the principle of least privilege, all declarations other than those you plan to modify should use const.\nThe rationale is that if a variable didn’t need to get written to, others working on the same codebase shouldn’t automatically be able to write to the object, and will need to consider whether they really need to reassign to the variable.\nUsing const also makes code more predictable when reasoning about flow of data.
Use your best judgement, and if applicable, consult the matter with the rest of your team.
\nThe majority of this handbook uses let declarations.
Another ECMAScript 2015 feature that TypeScript has is destructuring.\nFor a complete reference, see the article on the Mozilla Developer Network.\nIn this section, we’ll give a short overview.
\nThe simplest form of destructuring is array destructuring assignment:
\n\ntslet input = [1, 2];\nlet [first, second] = input;\nconsole.log(first); // outputs 1\nconsole.log(second); // outputs 2
This creates two new variables named first and second.\nThis is equivalent to using indexing, but is much more convenient:
\ntsfirst = input[0];\nsecond = input[1];
Destructuring works with already-declared variables as well:
\n\nts// swap variables\n[first, second] = [second, first];
And with parameters to a function:
\n\ntsfunction f([first, second]: [number, number]) {\n console.log(first);\n console.log(second);\n}\nf([1, 2]);
You can create a variable for the remaining items in a list using the syntax ...:
\ntslet [first, ...rest] = [1, 2, 3, 4];\nconsole.log(first); // outputs 1\nconsole.log(rest); // outputs [ 2, 3, 4 ]
Of course, since this is JavaScript, you can just ignore trailing elements you don’t care about:
\n\ntslet [first] = [1, 2, 3, 4];\nconsole.log(first); // outputs 1
Or other elements:
\n\ntslet [, second, , fourth] = [1, 2, 3, 4];\nconsole.log(second); // outputs 2\nconsole.log(fourth); // outputs 4
Tuples may be destructured like arrays; the destructuring variables get the types of the corresponding tuple elements:
\n\ntslet tuple: [number, string, boolean] = [7, \"hello\", true];\n\nlet [a, b, c] = tuple; // a: number, b: string, c: boolean
It’s an error to destructure a tuple beyond the range of its elements:
\n\ntslet [a, b, c, d] = tuple; // Error, no element at index 3
As with arrays, you can destructure the rest of the tuple with ..., to get a shorter tuple:
\ntslet [a, ...bc] = tuple; // bc: [string, boolean]\nlet [a, b, c, ...d] = tuple; // d: [], the empty tuple
Or ignore trailing elements, or other elements:
\n\ntslet [a] = tuple; // a: number\nlet [, b] = tuple; // b: string
You can also destructure objects:
\n\ntslet o = {\n a: \"foo\",\n b: 12,\n c: \"bar\"\n};\nlet { a, b } = o;
This creates new variables a and b from o.a and o.b.\nNotice that you can skip c if you don’t need it.
Like array destructuring, you can have assignment without declaration:
\n\nts({ a, b } = { a: \"baz\", b: 101 });
Notice that we had to surround this statement with parentheses.\nJavaScript normally parses a { as the start of block.
You can create a variable for the remaining items in an object using the syntax ...:
\ntslet { a, ...passthrough } = o;\nlet total = passthrough.b + passthrough.c.length;
You can also give different names to properties:
\n\ntslet { a: newName1, b: newName2 } = o;
Here the syntax starts to get confusing.\nYou can read a: newName1 as ”a as newName1”.\nThe direction is left-to-right, as if you had written:
\ntslet newName1 = o.a;\nlet newName2 = o.b;
Confusingly, the colon here does not indicate the type.\nThe type, if you specify it, still needs to be written after the entire destructuring:
\n\ntslet { a, b }: { a: string; b: number } = o;
Default values let you specify a default value in case a property is undefined:
\n\ntsfunction keepWholeObject(wholeObject: { a: string; b?: number }) {\n let { a, b = 1001 } = wholeObject;\n}
In this example the b? indicates that b is optional, so it may be undefined.\nkeepWholeObject now has a variable for wholeObject as well as the properties a and b, even if b is undefined.
Destructuring also works in function declarations.\nFor simple cases this is straightforward:
\n\ntstype C = { a: string; b?: number };\nfunction f({ a, b }: C): void {\n // ...\n}
But specifying defaults is more common for parameters, and getting defaults right with destructuring can be tricky.\nFirst of all, you need to remember to put the pattern before the default value.
\n\ntsfunction f({ a = \"\", b = 0 } = {}): void {\n // ...\n}\nf();
\n\nThe snippet above is an example of type inference, explained later in the handbook.
\n
Then, you need to remember to give a default for optional properties on the destructured property instead of the main initializer.\nRemember that C was defined with b optional:
\ntsfunction f({ a, b = 0 } = { a: \"\" }): void {\n // ...\n}\nf({ a: \"yes\" }); // ok, default b = 0\nf(); // ok, default to { a: \"\" }, which then defaults b = 0\nf({}); // error, 'a' is required if you supply an argument
Use destructuring with care.\nAs the previous example demonstrates, anything but the simplest destructuring expression is confusing.\nThis is especially true with deeply nested destructuring, which gets really hard to understand even without piling on renaming, default values, and type annotations.\nTry to keep destructuring expressions small and simple.\nYou can always write the assignments that destructuring would generate yourself.
\nThe spread operator is the opposite of destructuring.\nIt allows you to spread an array into another array, or an object into another object.\nFor example:
\n\ntslet first = [1, 2];\nlet second = [3, 4];\nlet bothPlus = [0, ...first, ...second, 5];
This gives bothPlus the value [0, 1, 2, 3, 4, 5].\nSpreading creates a shallow copy of first and second.\nThey are not changed by the spread.
You can also spread objects:
\n\ntslet defaults = { food: \"spicy\", price: \"$$\", ambiance: \"noisy\" };\nlet search = { ...defaults, food: \"rich\" };
Now search is { food: \"rich\", price: \"$$\", ambiance: \"noisy\" }.\nObject spreading is more complex than array spreading.\nLike array spreading, it proceeds from left-to-right, but the result is still an object.\nThis means that properties that come later in the spread object overwrite properties that come earlier.\nSo if we modify the previous example to spread at the end:
\ntslet defaults = { food: \"spicy\", price: \"$$\", ambiance: \"noisy\" };\nlet search = { food: \"rich\", ...defaults };
Then the food property in defaults overwrites food: \"rich\", which is not what we want in this case.
Object spread also has a couple of other surprising limits.\nFirst, it only includes an objects’\nown, enumerable properties.\nBasically, that means you lose methods when you spread instances of an object:
\n\ntsclass C {\n p = 12;\n m() {}\n}\nlet c = new C();\nlet clone = { ...c };\nclone.p; // ok\nclone.m(); // error!
Second, the TypeScript compiler doesn’t allow spreads of type parameters from generic functions.\nThat feature is expected in future versions of the language.
","headings":[{"value":"Variable Declarations","depth":1},{"value":"var declarations","depth":1},{"value":"Scoping rules","depth":2},{"value":"Variable capturing quirks","depth":2},{"value":"let declarations","depth":1},{"value":"Block-scoping","depth":2},{"value":"Re-declarations and Shadowing","depth":2},{"value":"Block-scoped variable capturing","depth":2},{"value":"const declarations","depth":1},{"value":"let vs. const","depth":1},{"value":"Destructuring","depth":1},{"value":"Array destructuring","depth":2},{"value":"Tuple destructuring","depth":2},{"value":"Object destructuring","depth":2},{"value":"Property renaming","depth":3},{"value":"Default values","depth":3},{"value":"Function declarations","depth":2},{"value":"Spread","depth":2}],"frontmatter":{"permalink":"/docs/handbook/variable-declarations.html","title":"Variable Declaration"}}},"pageContext":{"slug":"/docs/handbook/variable-declarations.html","isOldHandbook":true}}}