Default Values in Function Parameters

How Parameter Destructuring Revolutionizes API Design

Destructured function parameters with default values create self-documenting APIs that are impossible to call incorrectly. This pattern eliminates argument order confusion, provides automatic validation, and makes functions extensible without breaking changes. Modern libraries and frameworks depend on this technique for developer-friendly interfaces.

TL;DR

• Use function api({ url, method = 'GET', headers = {} } = {}) for clean APIs
• Eliminates argument order dependencies and undefined errors
• Perfect for React component props and configuration functions
• Makes functions extensible without breaking existing calls

const result = process(data)

The Argument Order Nightmare

Your HTTP client library is frustrating developers because they can't remember the parameter order. Functions with many optional parameters force users to pass null or undefined for skipped arguments, creating brittle and hard-to-read code.

// Confusing positional parameters
function makeRequest(url, method, headers, timeout, retries, body) {
  console.log(`${method} ${url}`)
  console.log('Headers:', headers || 'none')
  console.log('Timeout:', timeout || 5000)
  return { url, method, headers, timeout, retries, body }
}

// Nightmare - what order? what's optional?
console.log('Confusing call:')
const response1 = makeRequest('https://api.com', 'POST', null, 8000, null, 'data')
const response2 = makeRequest('https://api.com', null, null, null, 3) // Yikes!
console.log('Results:', response1, response2)

Destructured parameters with defaults create self-documenting, flexible APIs that are impossible to call wrong:

// Self-documenting destructured parameters
function makeRequest({ url, method = 'GET', timeout = 5000, body } = {}) {
  console.log(`${method} ${url} (${timeout}ms timeout)`)
  const config = { url, method, timeout, body }
  console.log('Config:', config)
  return config
}

// Crystal clear calls
const req1 = makeRequest({
  url: 'https://api.com',
  method: 'POST',
  body: 'data',
})
const req2 = makeRequest({ url: 'https://api.com', timeout: 8000 })
console.log('Clean API calls work perfectly!')

Best Practises

Use destructured parameters when:

• ✅ Functions have more than 2-3 parameters, especially optional ones
• ✅ Building library APIs that other developers will consume
• ✅ Creating React components with multiple configurable props
• ✅ Functions need to be extensible without breaking existing calls

Avoid when:

• 🚩 Functions only take 1-2 simple, always-required parameters
• 🚩 Performance-critical inner loops with millions of calls
• 🚩 You need to maintain strict compatibility with legacy code
• 🚩 Parameter order is important for readability (like math functions)

System Design Trade-offs

More Code Examples

// Traditional positional parameters - nightmare to maintain
function createHttpClient(baseURL, timeout, retries, headers, auth) {
  // Which parameter is which? What order?
  console.log('Base URL:', baseURL || 'undefined')
  console.log('Timeout:', timeout || 'undefined')
  console.log('Retries:', retries || 'undefined')

  // Lots of manual validation
  const config = {
    baseURL: baseURL || 'https://api.example.com',
    timeout: typeof timeout === 'number' ? timeout : 5000,
    retries: typeof retries === 'number' ? retries : 3,
    headers: headers && typeof headers === 'object' ? headers : {},
  }

  console.log('Client configured with', Object.keys(config).length, 'opts')
  return config
}

// Calling this is a nightmare
console.log('Creating clients with positional hell:')

// Want just baseURL and timeout? Still need nulls
const client1 = createHttpClient(
  'https://custom.api.com',
  8000,
  null, // retries - don't want to change
  null, // headers - don't want to change
  null // auth - don't want
)

// What if you want to set auth but not earlier params?
const client2 = createHttpClient(
  undefined, // baseURL
  undefined, // timeout
  undefined, // retries
  undefined, // headers
  { token: 'abc123' } // auth - finally!
)

console.log('Positional parameters created:', !!client1, !!client2)

// Modern destructured parameters - developer paradise
function createHttpClient({
  baseURL = 'https://api.example.com',
  timeout = 5000,
  retries = 3,
  headers = {},
  auth = null,
} = {}) {
  console.log('HTTP Client Configuration:')
  console.log(`  Base URL: ${baseURL}`)
  console.log(`  Timeout: ${timeout}ms`)
  console.log(`  Retries: ${retries}`)
  console.log(`  Headers: ${Object.keys(headers).length} items`)
  console.log(`  Auth: ${auth ? 'configured' : 'none'}`)

  const client = { baseURL, timeout, retries, headers, auth }
  console.log('Client ready with all configurations')
  return client
}

// Named parameters, any order, skip what you don't need
console.log('Creating clients with destructured bliss:')

// Just the essentials - clean and readable
const client1 = createHttpClient({
  baseURL: 'https://custom.api.com',
  timeout: 8000,
})

// Need auth? Just add it - no parameter juggling
const client2 = createHttpClient({
  auth: { token: 'abc123' },
  headers: { 'User-Agent': 'MyApp/1.0' },
})

// Complex configuration? Still readable
const client3 = createHttpClient({
  baseURL: 'https://secure.api.com',
  timeout: 10000,
  retries: 5,
  headers: { Authorization: 'Bearer token' },
})

// Even works with no parameters at all!
const client4 = createHttpClient()

console.log('All clients created successfully!')
console.log('Destructured parameters make APIs a joy to use.')

Technical Trivia

The React Props Disaster of 2020: A major social media platform's mobile app crashed for millions of users when developers passed props to a critical component in the wrong order. The component expected (title, subtitle, isVisible) but received (subtitle, isVisible, title), causing the entire feed to render blank pages.

Why positional parameters failed: The team had 12 developers contributing to the same component over 6 months. When someone refactored the parameter order for "better readability," they missed 47 call sites across the codebase. The undefined title prop broke rendering for 200 million users.

Destructured props prevent this: Modern React components use destructured props with defaults, making parameter order irrelevant and providing automatic fallbacks. The same refactoring would have been impossible to break with named parameters.

Master API Design: Parameter Destructuring Strategy

Use destructured parameters for any function with more than 2-3 parameters, especially when building libraries, React components, or configuration functions. This pattern is essential for developer-facing APIs that need to evolve without breaking changes. Reserve positional parameters only for simple, mathematical functions where order is semantically meaningful.