When utilizing a Dictionary data structure in TypeScript, we often need to iterate through key/value pairs.
One approach is to use a for...in loop:
for (const key in userDictionary) {\n const value = userDictionary[key];\n console.log(key, value)\n}\nThis works well, except that tslint will throw an error here. That's because tslint:
\n\nrequires a
\nfor...instatement to be filtered with an if statement.
This if statement must be immediate:
for (const key in userDictionary) {\n if (userDictionary.hasOwnProperty(key)) {\n ...\n\t}\n}\nThis approach is a bit inflexible, so a better approach is to use Object.entries, which returns key value/pairs in a different way:
Object.entries(userDictionary)\n .forEach(([key, value]) => console.log(key, value));\nThis avoids the tslint error, and is generally cleaner in my opinion.
One caveat is that Object.entries was only officially added in the ES2017 specification, so it still doesn't have perfect support.
After receiving a JSON response from a server, it is often necessary to perform some front-end sorting.
\nFor example, let’s say we're working on an HR web app and want to sort employees by the number of holidays they have remaining.
\nWe query the employee database and receive the following response:
\nconst response = [ \n { \n "id":"ITB89-001",\n "surname":"Marone",\n "given_name":"Peter",\n "title":"Developer",\n "holidays":"21"\n },\n { \n "id":"ITB89-008",\n "surname":"Gallant",\n "given_name":"Max",\n "title":"Developer",\n "holidays":"18"\n },\n { \n "id":"ITB89-006",\n "surname":"Reyes",\n "given_name":"Bernard",\n "title":"Manager",\n "holidays":"29"\n }\n]\nTo sort employees by remaining holidays in ascending order, we can use JavaScript's native sort function along with coercing the holidays property to a Number.
response.sort((a, b) => Number(a.holidays) - Number(b.holidays));\nIf we're looking to sort by string properties, such as surname in this case, we can use the localeCompare() method:
\n\nThe localeCompare() method returns a number indicating whether a reference string comes before or after or is the same as the given string in sort order.
\n
response.sort((a, b) => a.localeCompare(b));\nNote that the base localeCompare() is case insensitive, which works well for properties like names. If you need a case sensitive comparison, localeCompare() provides an options object which includes language and case options.
response.sort((a, b) => a.localeCompare(b, 'en', { sensitivity: 'case' }));\nIt is worth mentioning that localCompare() can also be used to sort numbers by setting the numeric property to true on the options object. However, using the sort with coerced numbers is a more common pattern.
Because of Angular's use of a rather complex compiler, it's not always clear when dependency injection actually occurs, and when certain services or properties become available.
\nAs a general rule, anything injected in the constructor is available when class properties are initialized.
\nFor example this class:
\nexport class Example {\n exampleProperty = "hello world";\n\n constructor(private store: Store) {}\n\n}\nGets compiled into this IIFE by Angular:
\nvar Example = (function() {\n function Example(store) {\n this.store = store;\n this.exampleProperty = "hello world";\n\t}\n})();\nWhatever is injected in the constructor is assigned first, so is available when any subsequent properties are initialized.
\nThat's why something like this works fine:
\nexport class Example {\n exampleStore = this.store;\n\n constructor(private store: Store) {}\n\n}\nAlthough this works, it is usually a better practice to initialize properties that rely on dependency injection in the ngOnInit() method.
export class Example implements OnInit {\n exampleStore: Store | undefined;\n\n constructor(private store: Store) {}\n\n ngOnInit() {\n this.exampleStore = store;\n }\n}\nThe assignment to exampleStore here is more explicit and generally easier to follow.
Many situations require you to generate a specific number of elements or iterations.
\nFor example, let's say we needed to generate a table with exactly 45 rows.
\nconst rows = 45;\n\nfunction addRow() {\n ..adds a row to the table\n}\nMany developers prefer chainable higher-order functions like forEach, map, and filter over counting loops.
It's perfectly possible to do this.
\nHere are some examples:
\nUsing the new keyword (not recommended):
new Array(rows).map(() => addRow());\nUsing Array.fill():
Array(rows).fill(undefined).map(() => addRow());\nUsing Array.from():
Array.from({ length: rows }, () => addRow());\nUsing the spread operator:
[...Array(rows)].map(() => addRow());\nJavaScript's Automatic Semicolon Insertion (ASI) is like a built-in linter that goes through your code and inserts semicolons in their proper places.
\nFor the most part ASI is silent and harmless. There is one case though (described below) where it is prone to causing issues.
\nSome of the most common places semicolons are inserted include the following:
\nAfter the return keyword:
return ouput\n// is parsed as\nreturn ouput;\nAfter an expression:
\n(a + b) * c\n// is parsed as\n(a + b) * c;\nAfter variable declarations:
\nconst exampleFlag = true\n// is parsed as\nconst exampleFlag = true;\nAfter continue and break statements:
for (const value of values) {\n console.log(value)\n break\n}\n// is parsed as\nfor (const value of values) {\n console.log(value);\n break;\n}\nAfter debugger statements:
function testCode() {\n debugger\n}\n// is parsed as\nfunction testCode() {\n debugger;\n}\nNow for the problem. As the JavaScript engine is parsing your code and inserting semicolons, if it encounters an illegal line break or closing bracket }, it will insert a semicolon on the previous valid statement or before the closing bracket.
For example:
\n{ 1 2 } 3\n// is parsed as\n{ 1 2 ;} 3;\nAnd:
\nreturn;\n{\n position: 'developer';\n}\n// is parsed as\nreturn;\n{\n position: 'developer';\n}\nDevelopers who choose not to use semicolons (relying purely on ASI) should at least use a good linter that will fix line breaks and prevent these types of bugs.
\n" }, { "title": "Understanding the Difference Between null and undefined in JavaScript", "body": "Undefined means that a reference has not been declared or has not been given a value.
Null is an assigned value that represents a null, empty, or non-existent reference.
In general, null is used to set something to empty, while undefined is empty because it has not been set.
Both null and undefined are falsy.
Consider undefined and null in relation to the following types of variables:
If you check an undeclared variable with typeof it will return undefined.
Any other operation will throw a Reference Error.
\nThe JavaScript engine sets declared variables to undefined during the Creation Phase, before assigning them values during the Execution Phase. For declared but unassigned variables, typeof will return undefined.
undefinedVariables set explicitly to undefined will behave the same as declared variables that have not been given values. This is the one case where an undefined value isn't coming from the JavaScript engine.
nullVariables set explicitly to null will have a typeof of object. Null is not set by the JavaScript engine and must be set explicitly.
It is often useful to filter objects in order to extract out relevant data, leaving a smaller object that is easier to work with.
\nConsider a simple object containing the number of customers per month for an online store.
\nconst customerCount = {\n "Jan": 1484,\n "Feb": 2536,\n "Mar": 1260,\n "Apr": 2431,\n "May": 2261,\n "Jun": 1242,\n "Jul": 2664,\n "Aug": 2348,\n "Sep": 3006,\n "Oct": 2161,\n "Nov": 1421,\n "Dec": 1290\n}\nLet's say we're only interested in customers during the first quarter of the year, i.e. January, February and March.
\nWe can extract this data by first creating an array of the data we need:
\nconst relevantMonths = ["Jan", "Feb", "Mar"];\nWe can then use reduce to filter for the relevant months:
relevantMonths.reduce((previousResult, month) => ({ ...previousResult, [month]: customerCount[month] }), {})\nWhat's happening here?
\nThe second argument of reduce takes an initial value, and here we're passing an empty object, which is what we'll start with.
For every month in the relevantMonths array, we then build onto the initial empty object by combining the object created during the previous iteration (if there was one), with a new month property that has the same value as month in the customerCount object.
The end result is a single object that contains only the properties specified in our relevantMonths array.
When working with months, it's common for developers to write out a literal list of month names:
\nconst months = ["January", "February", "March", ...];\nInstead of doing this, we can take advantage of JavaScript's built-in Date objects to generate a list for us:
const months = [...Array(12)].map((month, index) => new Date(0, index).toLocaleDateString('en-US', { month: 'long' }));\nHere we're creating an Array object with a length of 12 and spreading those 12 empty slots into an iterable array, which is then mapped over.
On each iteration, we're creating a new Date object and passing in a year and a month.
Passing in 0 for the year defaults to 1900 and the month value is zero-indexed, so we're generating dates of 1900-01-01, 1900-01-02, etc.
These dates are then formatted to only include the month name.
\nHere's a function which can be used to generate months in different formats:
\nfunction generateMonths(format: string = "long"): string[] {\n return [...Array(12)].map((month, index) => new Date(0, index).toLocaleDateString('en-US', { month: format }));\n}\n\ngenerateMonths("short"); // ["Jan", "Feb", "Mar", ... ]\ngenerateMonths("narrow"); // ["J", "F", "M", ... ]\ngenerateMonths("2-digit"); // ["01", "02", "03", ... ]\nSwapping two values often involves a temporary variable:
\nconst a = 1;\nconst b = 2;\nconst temp = a;\nconst swappedA = b;\nconst swappedB = temp;\nDestructuring can express the same idea in one line by binding new const values:
const a = 1;\nconst b = 2;\nconst [swappedA, swappedB] = [b, a];\n// swappedA is 2, swappedB is 1\nThe right-hand side is evaluated before assignment, so the original a and b are used correctly.
If you truly need to reassign existing bindings in place, destructuring assignment works too, but that requires let or var. For const-only code, prefer new bindings as above.
Search boxes, resize handlers, and scroll listeners can fire many times in a short period. Running expensive work on every event is wasteful.
\nDebouncing waits until the user pauses, then runs the handler once:
\nfunction debounce(fn, delayMs) {\n const state = { timeoutId: undefined };\n\n return (...args) => {\n clearTimeout(state.timeoutId);\n state.timeoutId = setTimeout(() => fn(...args), delayMs);\n };\n}\n\nconst onSearchInput = debounce((value: string) => {\n console.log("Searching for:", value);\n}, 300);\nEach time the wrapped function is called, the previous timer is cleared and a new one is started. The inner function only runs after delayMs passes with no new calls.
Hook it up to an input:
\ninput.addEventListener("input", event => {\n const target = event.target as HTMLInputElement;\n onSearchInput(target.value);\n});\nThree hundred milliseconds is a common starting point for typing. Resize handlers often use a slightly longer delay.
\n" }, { "title": "Removing Duplicates from Arrays with Set", "body": "When you need unique values from an array, a common approach is to loop and check whether each value was seen before.
\nA shorter option is to use a Set, which only stores unique values:
const tags = ["js", "typescript", "js", "react", "typescript"];\n\nconst uniqueTags = [...new Set(tags)];\n// ["js", "typescript", "react"]\nHere we pass the array into Set, then spread the result back into an array.
If you need to filter objects by a property, Set still helps for the keys:
const users = [\n { id: 1, team: "A" },\n { id: 2, team: "B" },\n { id: 3, team: "A" },\n];\n\nconst teams = [...new Set(users.map(user => user.team))];\n// ["A", "B"]\nSet uses strict equality (===), so { id: 1 } and { id: 1 } are treated as different objects. For primitives like strings and numbers, it works well.
The || operator is often used to provide a default when a value is "missing":
const count = 0;\nconst displayCount = count || 10;\n// displayCount is 10\nThat works for null and undefined, but it also treats 0, "", and false as missing. Sometimes that is what you want. Often it is not.
The nullish coalescing operator (??) only falls back when the value is null or undefined:
const count = 0;\nconst displayCount = count ?? 10;\n// displayCount is 0\n\nconst name = "";\nconst displayName = name ?? "Guest";\n// displayName is ""\nA practical pattern is combining optional chaining with nullish coalescing:
\nconst city = user.address?.city ?? "Unknown";\nUse || when any falsy value should trigger the default. Use ?? when only null or undefined should.
To get the last item in an array, many developers write:
\nconst items = ["a", "b", "c"];\nconst last = items[items.length - 1];\nThat works, but it is awkward when you want the second-to-last item or a dynamic offset from the end.
\nArray.prototype.at() accepts negative indices:
const items = ["a", "b", "c"];\n\nitems.at(-1); // "c"\nitems.at(-2); // "b"\nitems.at(0); // "a"\nIf the index is out of range, at() returns undefined instead of throwing:
items.at(10); // undefined\nFor positive indices, at() behaves like bracket notation. The main benefit is readable access from the end without repeating length.
The spread operator copies an object one level deep:
\nconst original = {\n name: "Ada",\n scores: [10, 20],\n};\n\nconst copy = { ...original };\ncopy.name = "Grace";\ncopy.scores.push(30);\n\nconsole.log(original.scores); // [10, 20, 30]\nChanging copy.name did not affect original. Pushing to copy.scores did, because both objects share the same array reference.
When you need a full clone, structuredClone() is built in:
const deep = structuredClone(original);\ndeep.scores.push(30);\n\nconsole.log(original.scores); // [10, 20]\nstructuredClone() handles nested objects, arrays, dates, and many other types. It does not clone functions or DOM nodes.
The older JSON.parse(JSON.stringify(obj)) trick still appears in legacy code, but it drops undefined, functions, and Date objects. Prefer structuredClone() when you need a true deep copy in modern browsers and Node.
Given a flat list of records, it is common to group them by a field—for example, tasks by status or orders by customer.
\nObject.groupBy() makes this straightforward:
const tasks = [\n { title: "Write tests", status: "todo" },\n { title: "Ship feature", status: "done" },\n { title: "Fix bug", status: "todo" },\n];\n\nconst byStatus = Object.groupBy(tasks, task => task.status);\nThe result is an object whose keys are the group names and whose values are arrays of matching items:
\n// {\n// todo: [{ title: "Write tests", ... }, { title: "Fix bug", ... }],\n// done: [{ title: "Ship feature", ... }]\n// }\nBefore Object.groupBy(), the same result was usually built with reduce:
const byStatus = tasks.reduce<Record<string, typeof tasks>>((groups, task) => {\n const key = task.status;\n groups[key] = groups[key] ?? [];\n groups[key].push(task);\n return groups;\n}, {});\nBoth approaches avoid manual loops and nested filter calls for each group.
Promise.all() runs several async tasks in parallel and resolves when every one succeeds:
const [user, posts] = await Promise.all([\n fetchUser(id),\n fetchPosts(id),\n]);\nIf any promise rejects, Promise.all() rejects immediately and you do not get partial results.
When you want every outcome—success or failure—use Promise.allSettled():
const results = await Promise.allSettled([\n fetchUser(id),\n fetchPosts(id),\n fetchComments(id),\n]);\n\nresults.forEach(result => {\n if (result.status === "fulfilled") {\n console.log(result.value);\n } else {\n console.error(result.reason);\n }\n});\nThis pattern is useful for dashboards or batch jobs where one failure should not cancel the rest.
\nPromise.allSettled() always resolves. It never rejects because an individual task failed. Check each status before using value or reason.
Nested arrays show up when mapping over lists that return arrays:
\nconst teams = [\n ["Ada", "Grace"],\n ["Lin", "Edsger"],\n];\n\nteams.map(team => team);\n// [["Ada", "Grace"], ["Lin", "Edsger"]]\nflat() collapses one level by default:
teams.flat();\n// ["Ada", "Grace", "Lin", "Edsger"]\nFor deeper nesting, pass a depth:
\nconst nested = [1, [2, [3, [4]]]];\n\nnested.flat(1); // [1, 2, [3, [4]]]\nnested.flat(2); // [1, 2, 3, [4]]\nnested.flat(Infinity); // [1, 2, 3, 4]\nA common follow-up is flatMap(), which maps and flattens in one step:
const sentences = ["hello world", "foo bar"];\n\nsentences.flatMap(sentence => sentence.split(" "));\n// ["hello", "world", "foo", "bar"]\nThat is often cleaner than map(...).flat() when each item produces an array.
The in operator checks whether a key exists anywhere on an object, including inherited properties:
const user = { name: "Ada" };\n\n"name" in user; // true\n"toString" in user; // true (inherited from Object.prototype)\nObject.hasOwn() checks only own properties:
Object.hasOwn(user, "name"); // true\nObject.hasOwn(user, "toString"); // false\nUse hasOwn() when you are iterating or copying keys and want to ignore prototype properties.
For optional values, undefined checks are still common:
if (user.nickname !== undefined) {\n // nickname was set (even if empty string)\n}\nCombining these ideas avoids bugs when parsing JSON or merging config objects where missing keys and inherited keys mean different things.
\n" }, { "title": "Communicating with postMessage", "body": "window.postMessage() lets scripts send data across windows, tabs, and iframes—even when they are on different origins. The receiving page listens with a message event.
Parent sending to an iframe:
\nconst iframe = document.querySelector("iframe");\niframe?.contentWindow?.postMessage(\n { type: "resize", height: 400 },\n "https://example.com",\n);\nChild receiving:
\nwindow.addEventListener("message", (event) => {\n if (event.origin !== "https://example.com") {\n return;\n }\n\n if (event.data?.type === "resize") {\n document.body.style.height = `${event.data.height}px`;\n }\n});\nAlways validate event.origin before trusting the payload. The target origin argument on postMessage is not a security boundary on its own—it tells the browser which origin should receive the message.
For same-origin communication between workers or windows you control, postMessage is still useful because it keeps the API consistent and decouples senders from receivers.
The inherit keyword tells a property to use the same computed value as its parent element. It is useful when a child should explicitly pick up a value from above, especially inside components where local styles might otherwise reset things.
.card {\n color: #333;\n}\n\n.card__label {\n color: inherit;\n}\nSome properties inherit by default (color, font-family, line-height). Others do not (margin, border, background). For those, inherit is the way to say "use the parent's value" without repeating it.
.sidebar {\n border-color: #ccc;\n}\n\n.sidebar a {\n border-color: inherit;\n}\ninherit is not the same as initial (browser default) or unset (inherit if the property normally inherits, otherwise initial). When you want the parent’s computed value specifically, reach for inherit.
Sometimes you need to add a stylesheet rule at runtime—for example, highlighting a search term or applying a theme token that was not known when the page loaded.
\nCSSStyleSheet.insertRule() adds a rule at a given index:
const sheet = document.styleSheets[0];\nsheet.insertRule(".highlight { background: yellow; }", sheet.cssRules.length);\nThe second argument is the index. Passing cssRules.length appends to the end. Rules are strings in full CSS syntax, including the selector.
For styles attached via <style> or new CSSStyleSheet(), the same API applies. With constructable stylesheets adopted into the document, you can build rules before attaching:
const sheet = new CSSStyleSheet();\nsheet.replaceSync("body { margin: 0; }");\nsheet.insertRule(":root { --accent: #3366cc; }", sheet.cssRules.length);\ndocument.adoptedStyleSheets = [...document.adoptedStyleSheets, sheet];\ndeleteRule(index) removes a rule by position. Keep track of indices if you plan to remove rules later, since inserting at the end is the simplest approach when order does not matter.
Modern JavaScript has three ways to declare variables. They differ in scope, hoisting, and whether rebinding is allowed.
\nconst declares a binding that cannot be reassigned. The value can still change if it is an object or array:
const user = { name: "Ada" };\nuser.name = "Grace"; // allowed\n\nconst count = 1;\ncount = 2; // SyntaxError\nlet declares a block-scoped binding that can be reassigned:
let total = 0;\nfor (let i = 0; i < 3; i++) {\n total += i;\n}\nvar is function-scoped and hoisted with an initial value of undefined:
function example() {\n console.log(x); // undefined (not a ReferenceError)\n var x = 1;\n}\nPrefer const by default and let when you need to reassign. Avoid var in new code—it does not respect block scope, which makes loops and conditionals harder to reason about.
for (var i = 0; i < 3; i++) {\n setTimeout(() => console.log(i), 0);\n}\n// logs 3, 3, 3\n\nfor (let i = 0; i < 3; i++) {\n setTimeout(() => console.log(i), 0);\n}\n// logs 0, 1, 2\nEach let iteration gets its own binding. Each var iteration shares one.
Plain objects work well for fixed keys and JSON-shaped data. Map is often a better fit when keys are unknown at compile time, keys are not strings, or you need reliable size and iteration order.
Objects coerce keys to strings:
\nconst obj: Record<string, number> = {};\nobj[{} as unknown as string] = 1; // awkward; keys become "[object Object]"\nMap accepts any value as a key:
const map = new Map<object, number>();\nconst key = { id: 1 };\nmap.set(key, 42);\nmap.get(key); // 42\nMap exposes size directly and iterates in insertion order:
const map = new Map([\n ["a", 1],\n ["b", 2],\n]);\n\nmap.size; // 2\n\nfor (const [key, value] of map) {\n console.log(key, value);\n}\nUse a plain object when the shape is stable, you need JSON serialization, or you are modeling a record with named fields. Use Map for caches, indexes keyed by entities, or any collection where keys are dynamic or non-string.
Global and sticky regular expressions track where the last match ended using the lastIndex property. The next call to exec() or test() starts searching from that position.
const pattern = /a/g;\nconst text = "aba";\n\npattern.test(text); // true, lastIndex is 1\npattern.test(text); // true, lastIndex is 3\npattern.test(text); // false, lastIndex resets to 0\nWithout the g or y flag, lastIndex is ignored and always stays at 0.
This matters when reusing the same RegExp instance in a loop:
const pattern = /\\d+/g;\nconst text = "a1b22c333";\n\nlet match: RegExpExecArray | null;\nwhile ((match = pattern.exec(text)) !== null) {\n console.log(match[0]);\n}\n// "1", "22", "333"\nIf you only need to know whether a string matches, create a fresh regex or reset lastIndex before each use:
pattern.lastIndex = 0;\npattern.test(text);\nFor one-off checks, text.match(/pattern/g) or pattern.test(text) on a new instance avoids lastIndex surprises entirely.
let and const are hoisted like var, but they are not initialized until their declaration line runs. The span from the start of the block until that line is the temporal dead zone (TDZ).
Accessing the binding in the TDZ throws a ReferenceError:
console.log(count); // ReferenceError\nconst count = 1;\ntypeof behaves differently for undeclared variables versus TDZ variables:
typeof notDeclared; // "undefined"\n\ntypeof inTdz; // ReferenceError\nlet inTdz = 1;\nThe TDZ also applies to function parameters and default values, which are evaluated left to right:
\nfunction example(a = b, b = 1) {\n return a + b;\n}\n\nexample(); // ReferenceError: Cannot access 'b' before initialization\nThis is why let loop variables work as expected—each iteration gets a fresh binding in its own scope—and why referencing a const before its declaration fails even though the name appears later in the same block.
A WeakMap is like a Map, but its keys must be objects and they are held weakly. If nothing else references a key object, it can be garbage-collected and the entry disappears from the map.
let user = { id: 1 };\nconst metadata = new WeakMap<object, { visits: number }>();\n\nmetadata.set(user, { visits: 1 });\nmetadata.get(user); // { visits: 1 }\n\nuser = null;\n// The { id: 1 } object and its WeakMap entry can now be collected.\nYou cannot iterate a WeakMap and there is no size property. That is by design—the engine does not keep a strong list of weak keys.
A common pattern is attaching private data to DOM nodes or class instances without polluting the object itself:
\nconst privateData = new WeakMap<HTMLElement, { listener: () => void }>();\n\nfunction register(element: HTMLElement, listener: () => void) {\n privateData.set(element, { listener });\n element.addEventListener("click", listener);\n}\n\nfunction unregister(element: HTMLElement) {\n const data = privateData.get(element);\n if (data) {\n element.removeEventListener("click", data.listener);\n privateData.delete(element);\n }\n}\nWhen the element is removed from the document and no longer referenced, its metadata goes away with it. Use a regular Map when you need enumeration, primitive keys, or a known entry count.