JavaScript Functions Practice

JavaScript has four main function syntaxes, each with different behavior:

// 1. Function declaration (hoisted, has own 'this')
function add(a, b) {
  return a + b;
}

// 2. Function expression (not hoisted, has own 'this')
const add = function(a, b) {
  return a + b;
};

// 3. Arrow function (not hoisted, captures outer 'this')
const add = (a, b) => a + b;

// 4. Async function (returns a Promise, enables await)
async function fetchData() {
  const res = await fetch('/api/data');
  return res.json();
}

The differences matter when you use them as methods or callbacks. Async functions can use any of the first three syntaxes (async function, async () => {}, etc.). If you're coming from Python, the Python vs JavaScript functions comparison highlights the key differences in scoping and this binding.

Function declarations are fully hoisted, moved to the top of their scope:

greet("Alice"); // Works! Declaration is hoisted

function greet(name) {
  console.log(`Hello, ${name}`);
}

Function expressions are NOT hoisted the same way:

greet("Alice"); // TypeError: greet is not a function

var greet = function(name) {
  console.log(`Hello, ${name}`);
};

With var, the variable greet is hoisted as undefined, so calling it throws an error.

With let or const, it's even stricter. You get a ReferenceError (temporal dead zone):

greet("Alice"); // ReferenceError: Cannot access 'greet' before initialization

const greet = (name) => console.log(`Hello, ${name}`);

Rule of thumb: Use declarations for functions you need to call before they appear. Use expressions/arrows for callbacks and inline functions.

Arrow functions are great for callbacks because they're concise and capture this lexically:

// Good: arrow in callback
const doubled = numbers.map(n => n * 2);

// Good: arrow preserves 'this' in event handler
class Timer {
  count = 0;
  start() {
    setInterval(() => {
      this.count++; // 'this' refers to Timer instance
    }, 1000);
  }
}

Do NOT use arrows as object methods:

// BAD: arrow as method
const user = {
  name: "Alice",
  greet: () => {
    console.log(`Hi, I'm ${this.name}`); // 'this' is NOT user!
  }
};
user.greet(); // "Hi, I'm undefined"

// GOOD: regular function as method
const user = {
  name: "Alice",
  greet() {
    console.log(`Hi, I'm ${this.name}`); // 'this' is user
  }
};
user.greet(); // "Hi, I'm Alice"

Arrow function limitations

Arrow functions cannot:

• Be used as constructors (new Arrow() throws TypeError)
• Access arguments (use rest parameters instead)
• Be used with call/apply/bind to change this

Every function in JavaScript is a closure. It retains access to variables from its outer scope:

function createCounter() {
  let count = 0; // This variable is "closed over"

  return function increment() {
    count += 1;
    return count;
  };
}

const counter = createCounter();
counter(); // 1
counter(); // 2
counter(); // 3

The inner function increment keeps access to count even after createCounter has returned.

Common closure patterns

Private state:

function createWallet(initial) {
  let balance = initial;
  return {
    deposit: (amount) => { balance += amount; },
    withdraw: (amount) => { balance -= amount; },
    getBalance: () => balance
  };
}

Memoization: The closure-based factory pattern here is also at the heart of the Strategy design pattern, where you pass different functions to change behavior at runtime.

function memoize(fn) {
  const cache = {};
  return function(...args) {
    const key = JSON.stringify(args);
    if (!(key in cache)) {
      cache[key] = fn(...args);
    }
    return cache[key];
  };
}

The closure trap (capturing by reference)

Closures capture variables by reference, not by value:

// BUG: All functions log 3
const funcs = [];
for (var i = 0; i < 3; i++) {
  funcs.push(function() { console.log(i); });
}
funcs[0](); // 3 (not 0!)

// FIX 1: Use let (block scoped)
for (let i = 0; i < 3; i++) {
  funcs.push(function() { console.log(i); });
}

// FIX 2: Create a new scope with IIFE
for (var i = 0; i < 3; i++) {
  funcs.push((function(j) {
    return function() { console.log(j); };
  })(i));
}

Default parameters

Defaults apply when an argument is undefined or missing, NOT when it's null:

function greet(name = "stranger") {
  console.log(`Hello, ${name}`);
}

greet();          // "Hello, stranger"
greet(undefined); // "Hello, stranger"
greet(null);      // "Hello, null" (null does NOT trigger default!)
greet("");        // "Hello, " (empty string does NOT trigger default)

Rest parameters

Rest parameters collect remaining arguments into a real array:

function sum(...numbers) {
  return numbers.reduce((a, b) => a + b, 0);
}

sum(1, 2, 3, 4); // 10

Why rest params beat arguments: For a detailed comparison of how TypeScript adds type safety to these patterns, see the JavaScript vs TypeScript functions comparison.

• arguments is array-like (no .map, .filter, etc.)
• Arrow functions don't have arguments
• Rest params are explicit and readable

// Old way (avoid)
function sum() {
  return Array.from(arguments).reduce((a, b) => a + b, 0);
}

// Modern way (prefer)
const sum = (...nums) => nums.reduce((a, b) => a + b, 0);

This is a common gotcha. Curly braces are ambiguous because they could be a block or an object literal:

// BUG: Returns undefined (braces parsed as block)
const getUser = () => { name: "Alice" };

// FIX: Wrap object in parentheses
const getUser = () => ({ name: "Alice" });

Without parentheses, { name: "Alice" } is parsed as a block statement with a labeled expression, which returns undefined.

• MDN: Functions
• MDN: Arrow function expressions
• MDN: Closures
• MDN: Default parameters
• MDN: Rest parameters