How to Take Advantage of JavaScript Default Parameters for Dependency Injection

As JavaScript applications grow in size and complexity, structuring code into modular, loosely coupled units becomes increasingly important. Dependency injection (DI) is a key technique for achieving this, but the way you implement it can have a big impact on the simplicity and readability of your code.

In this article, we‘ll explore how to leverage a core feature of JavaScript—default function parameters—to implement dependency injection in an elegant and lightweight way. We‘ll cover the benefits of this approach and walk through a real-world example to demonstrate it in action.

What is Dependency Injection?

Dependency injection is a software design pattern in which an object receives its dependencies from an external source rather than creating them itself. The key idea is to invert control by separating the construction of dependencies from their use.

Why is this useful? It promotes loose coupling between modules, making the code more flexible, reusable, and testable. Dependencies can be swapped out without modifying the modules that use them. This is especially valuable for testing, where you can inject mock dependencies to isolate the code under test.

As Mark Seemann, author of Dependency Injection in .NET, puts it:

DI is about writing maintainable code. It helps keep your code flexible, testable, and modular by decoupling concrete dependencies from the code that depends on them.

While DI is often associated with object-oriented languages like Java and C#, it‘s a universal principle that applies equally well to JavaScript‘s functional programming style.

DI Patterns in JavaScript

There are several ways to implement dependency injection in JavaScript. Let‘s look at a few common patterns.

Constructor Injection

With constructor injection, dependencies are passed to a class constructor when it‘s instantiated:

class UserService {
  constructor(userRepo) {
    this.userRepo = userRepo;
  }

  getUser(id) {
    return this.userRepo.get(id);
  }
}

const userRepo = new UserRepository();
const userService = new UserService(userRepo);

The UserService class takes its userRepo dependency as a constructor argument, allowing it to be injected from outside.

Property Injection

Property injection is similar, but the dependencies are set as properties on the object after it‘s constructed:

class UserService {
  getUser(id) {
    return this.userRepo.get(id);
  }
}

const userService = new UserService();
userService.userRepo = new UserRepository();

This can be useful if the dependencies aren‘t available when the object is first created.

DI Container Libraries

For larger applications with complex dependency graphs, it‘s common to use a dedicated DI container library like InversifyJS or awilix. These automate the process of instantiating and injecting dependencies.

Here‘s an example using InversifyJS:

import { Container, injectable, inject } from ‘inversify‘;

@injectable()
class UserRepository {
  get(id: number) { /* ... */ }
}

@injectable()
class UserService {
  constructor(@inject(UserRepository) private userRepo: UserRepository) {}

  getUser(id: number) {
    return this.userRepo.get(id);
  }
}

const container = new Container();
container.bind(UserRepository).toSelf();
container.bind(UserService).toSelf();

const userService = container.get(UserService);

The @injectable and @inject decorators tell InversifyJS which classes can be injected and what dependencies they require. The Container class handles the instantiation and injection of the dependencies.

While powerful, DI container libraries add a layer of complexity that may be overkill for small to medium-sized applications. This is where JavaScript‘s default parameters come in.

Default Parameters: A Lightweight DI Solution

ECMAScript 2015 (ES6) introduced default function parameters, which allow you to specify a default value for a parameter if none is provided or if the value is undefined. It turns out this is a great fit for dependency injection.

Here‘s how it works:

function createUserService(userRepo = new UserRepository()) {
  return {
    getUser: id => userRepo.get(id) 
  };
}

const userService = createUserService();
userService.getUser(123);

In this example, the createUserService factory function takes an optional userRepo parameter with a default value of new UserRepository(). If no argument is passed, it automatically uses the default repository implementation.

To inject a different implementation, you simply pass it as an argument:

const mockUserRepo = {
  get: id => ({ id, name: ‘Test User‘ })
};

const userService = createUserService(mockUserRepo);

This overrides the default UserRepository with a mock implementation for testing.

Using default parameters for DI has several advantages:

1. It‘s lightweight and easy to understand, with no additional libraries or complex setup required.
2. It makes the default dependencies explicit and obvious at the point of use.
3. It allows dependencies to be overridden when needed, while providing sensible defaults.
4. It keeps the dependency injection transparent to the consumer in the most common case.

As JavaScript expert Eric Elliott puts it in his article Mocking is a Code Smell:

If your unit tests are littered with mocks, it‘s time to rethink your approach. In JavaScript, we can simply use higher-order functions and closure scope to inject dependencies. No third party libraries or magic containers required.

Of course, default parameters aren‘t a complete replacement for DI containers. For very large applications with hundreds of dependencies, the explicitness and centralized management of a container can be beneficial. But for many projects, default parameters provide a simple, low-ceremony way to get the benefits of DI.

Default Parameters: Under the Hood

To understand how default parameters can be used effectively for DI, it‘s helpful to know a bit about how they work behind the scenes.

When you define a function with default parameters, JavaScript effectively creates a new scope containing the parameters and their default values. This scope is accessible to the function body. If an argument is passed for a parameter, it shadows the default value in the scope.

Here‘s a simplified representation of how the JavaScript engine might interpret our earlier createUserService example:

function createUserService(userRepo) {
  const scope = {
    userRepo: userRepo !== undefined ? userRepo : new UserRepository()
  };

  return {
    getUser: id => scope.userRepo.get(id) 
  };
}

The default value expression new UserRepository() is evaluated lazily, only if userRepo is undefined. This means you can put expensive computations or I/O in default value expressions without worrying about the performance impact when an explicit value is passed.

One thing to watch out for is that default value expressions are evaluated every time the function is called, not just once when the function is defined. If your default value has side effects or is expensive to compute, consider defining it outside the function and referencing it by name instead:

const defaultUserRepo = new UserRepository();

function createUserService(userRepo = defaultUserRepo) {
  // ...
}

This ensures the default repository is only created once, not on every function call.

Beyond the Basics: A Real-World Example

To see the default parameter DI pattern in action, let‘s walk through a more realistic example of a full-stack JavaScript application.

Imagine we‘re building a server-side Node.js API with a /users endpoint that fetches user data from a database. We‘ll use the popular Express framework for the API layer and a fictional UserRepository class for data access.

Here‘s what the core API module might look like:

// users-api.js
import express from ‘express‘;
import UserRepository from ‘./user-repository‘;

export default function createUsersApi(userRepo = new UserRepository()) {
  const router = express.Router();

  router.get(‘/:id‘, async (req, res, next) => {
    try {
      const user = await userRepo.get(req.params.id);
      res.json(user);
    } catch (err) {
      next(err);
    }
  });

  return router;
}

The createUsersApi function is a factory that creates an Express router with a route handler for GET /users/:id. It takes an optional userRepo parameter with a default UserRepository instance. The route handler uses this repository to fetch the user data.

In the application entry point, we mount this router into the main Express app:

// app.js
import express from ‘express‘;
import createUsersApi from ‘./users-api‘;

const app = express();

app.use(‘/users‘, createUsersApi());

app.listen(3000, () => {
  console.log(‘Server listening on port 3000‘);  
});

Here, createUsersApi is called with no arguments, so it defaults to using a real UserRepository that connects to the database.

But in a unit test for the API route, we can pass a mock repository to isolate it from the database:

// users-api.test.js
import request from ‘supertest‘;
import express from ‘express‘;
import createUsersApi from ‘./users-api‘;

describe(‘GET /users/:id‘, () => {
  it(‘responds with the requested user‘, async () => {
    const mockUserRepo = {
      get: id => Promise.resolve({ id, name: ‘Alice‘ }) 
    };

    const app = express();
    app.use(‘/users‘, createUsersApi(mockUserRepo));

    const res = await request(app)
      .get(‘/users/123‘)
      .expect(200);

    expect(res.body).toEqual({ id: ‘123‘, name: ‘Alice‘ });
  });
});

The mock repository is a simple object with a get method that always resolves to a hardcoded user object. By passing this mock to createUsersApi, we can test the API route handler in isolation, without needing a real database connection.

This example demonstrates how default parameters can help simplify dependency injection in a Node.js application. The dependencies are clearly defined and easily overridable for testing, without a lot of boilerplate or indirection.

Expert Perspectives

Don‘t just take my word for it. Here‘s what some respected figures in the JavaScript community have to say about DI and default parameters:

I prefer using default parameters wherever it‘s clean and readable to do so. Default parameters are one honking great idea — let‘s do more of those!

– Dr. Axel Rauschmayer, author of Exploring JS

Default parameters give you a terse, declarative way to define function parameters that can be easily overridden as needed, either for testing or for changing the behavior of the code. They‘re a powerful tool for creating clean, modular code.

– Addy Osmani, Engineering Manager at Google

The default parameter DI trick is a great compromise. It makes the common case simple, without precluding a more complex solution if needed. That‘s the essence of good API design in my book.

– Mark Dalgleish, co-creator of CSS Modules

These endorsements underscore the practicality and expressiveness of using default parameters for dependency injection in real-world JavaScript code.

The Future of DI in JavaScript

Looking ahead, there are some exciting developments on the horizon that could impact how we approach DI in JavaScript.

One is the TC39 decorator proposal. Decorators are a way to modify classes and properties at design time, similar to annotations in Java. They‘re a natural fit for declaratively specifying dependencies on a class, as we saw with the InversifyJS example earlier.

If the decorator proposal is adopted, we may see more use of class-based DI powered by decorators, especially in larger applications. However, the proposal is still in flux and not yet part of the JavaScript standard.

Another trend is the growing popularity of functional programming principles in JavaScript. As we‘ve seen, functional techniques like higher-order functions and closure scope are a natural fit for DI. Libraries like fp-ts and Rambda make it easy to write modular, testable code in a functional style.

Ultimately, the specific DI pattern you use is less important than the principles behind it: loose coupling, modularity, and testability. As long as your code embraces these principles, you‘ll be well-positioned to write maintainable JavaScript applications, no matter what the future holds.

Conclusion

Dependency injection is a powerful technique for writing modular, testable code. While there are many ways to implement DI in JavaScript, default parameters offer a particularly elegant and lightweight solution.

By specifying dependencies as default parameters to a function or constructor, you can make the dependencies explicit and easily overridable, without a lot of boilerplate or complexity. This keeps your code simple and readable while still providing the benefits of DI.

Of course, default parameters aren‘t a silver bullet. For very large applications with complex dependency graphs, a full-blown DI container may be a better fit. But for many small to medium-sized projects, default parameters are a great way to get started with DI.

As with any pattern, the key is to use it judiciously and to always prioritize clarity and maintainability over cleverness or dogmatism. With a pragmatic approach and an eye for design, default parameter dependency injection can be a valuable addition to any JavaScript developer‘s toolkit.