Angular inject() vs. Constructor Injection: When to Use Each

Angular supports both constructor injection and the inject() function. inject() can declare a dependency in a class field or an Angular injection context, such as a provider factory. Constructors remain valid; use inject() where it clarifies dependencies or fits a functional API. Calling it outside an injection context throws an error. For the official migration steps, see Angular’s inject() function migration, as well as the full API reference for Angular's inject() API.

The Traditional Constructor Pattern

Constructor injection is still supported. The common pattern looks like this:

constructor(private abc: AbcService) {}

While this works well, constructors can quickly become crowded when injecting multiple services, and the pattern doesn't translate well to functional or factory-based code. Developers often found themselves adding unused constructor parameters temporarily or reorganizing constructor signatures to keep the code readable.

The New inject() Class Field Approach

Angular's new convention allows developers to declare dependencies directly inside the class without a constructor:

private readonly abc = inject(AbcService);

This approach reduces boilerplate and makes dependencies easier to locate and manage. inject() can also be called in supported injection contexts, including provider factories and functional guards. It cannot be called from an arbitrary method or after the instance has been created. It also supports refactoring, since developers can add or remove services without modifying constructor signatures or breaking inheritance patterns.

Key Advantages of the inject() Pattern

Using inject() provides several benefits:

• Cleaner, constructor-free components
• Better readability with explicit, per-field injection
• Works in functional and factory APIs
• Simplifies unit testing and mocking
• Aligns with Angular's standalone architecture
• Makes adding new dependencies less intrusive

Final Thoughts

Use inject() when field-level dependencies or a functional Angular API make the code clearer. Constructor injection remains a sound option for existing classes. Before migrating, review where an injection context exists and run the Angular migration schematic and tests against your project’s Angular version.