Injectable decorator in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a service is decorated with @Injectable() in NestJS?

Consider a service class in NestJS decorated with @Injectable(). What is the main effect of this decorator on the service?

NestJS

import { Injectable } from '@nestjs/common';

@Injectable()
export class MyService {
  getMessage() {
    return 'Hello from service';
  }
}

A It marks the class as a provider that can be injected into other classes by NestJS's dependency injection system.

B It makes the class a middleware that intercepts requests before reaching controllers.

C It automatically registers the class as a controller to handle HTTP requests.

D It disables dependency injection for the class, making it standalone.

💡 Hint

Think about what NestJS needs to do to create and share instances of this class.

The @Injectable() decorator tells NestJS that this class can be managed by its dependency injection system. This allows other classes to receive instances of this service automatically.

📝 Syntax

intermediate

Which code snippet correctly uses @Injectable() with a scope in NestJS?

In NestJS, you can specify the scope of an injectable provider. Which of the following code snippets correctly sets the scope to Scope.REQUEST?

A

import { Injectable, Scope } from '@nestjs/common';

@Injectable({ scope: 'REQUEST' })
export class RequestService {}

B

import { Injectable } from '@nestjs/common';

@Injectable(Scope.REQUEST)
export class RequestService {}

C

import { Injectable, Scope } from '@nestjs/common';

@Injectable({ scope: Scope.REQUEST })
export class RequestService {}

D

import { Injectable } from '@nestjs/common';

@Injectable({ scope: Scope.REQUEST })
export class RequestService {}

💡 Hint

Check how the scope option is passed as an object property.

The correct syntax is to pass an object with a scope property set to Scope.REQUEST. Option C correctly imports Scope and uses it inside the object.

🔧 Debug

advanced

Why does this NestJS service fail to inject into a controller?

Given the following code, why does NestJS throw an error that MyService is not a provider?

NestJS

import { Injectable } from '@nestjs/common';

export class MyService {
  getData() {
    return 'data';
  }
}

import { Controller, Get } from '@nestjs/common';

@Controller()
export class MyController {
  constructor(private readonly myService: MyService) {}

  @Get()
  get() {
    return this.myService.getData();
  }
}

A Because the service method getData() is not marked as public.

B Because the controller is missing the @Injectable() decorator.

C Because the service is not imported into the controller file.

D Because MyService is missing the @Injectable() decorator, so NestJS does not recognize it as a provider.

💡 Hint

Think about what NestJS requires to manage a class as a provider.

Without the @Injectable() decorator, NestJS does not treat the class as a provider and cannot inject it into other classes.

❓ state_output

advanced

What is the output when injecting a transient scoped service multiple times?

Consider this NestJS service with transient scope injected twice into a controller. What will be the output of the following code?

NestJS

import { Injectable, Scope } from '@nestjs/common';

@Injectable({ scope: Scope.TRANSIENT })
export class TransientService {
  id = Math.random();
}

import { Controller, Get } from '@nestjs/common';

@Controller()
export class TestController {
  constructor(
    private readonly service1: TransientService,
    private readonly service2: TransientService
  ) {}

  @Get()
  getIds() {
    return { id1: this.service1.id, id2: this.service2.id };
  }
}

A Both id1 and id2 will be the same random number because the service is singleton by default.

B id1 and id2 will be different random numbers because transient scope creates a new instance each injection.

C The code will throw an error because transient scope services cannot be injected twice.

D Both id1 and id2 will be undefined because the id property is not initialized.

💡 Hint

Recall what transient scope means for service instances.

Transient scope means a new instance is created every time the service is injected. So service1 and service2 are different instances with different random ids.

🧠 Conceptual

expert

Which option best describes the role of @Injectable() in NestJS's dependency injection system?

Choose the most accurate description of what the @Injectable() decorator does in NestJS.

A It registers the class as a provider in the NestJS dependency injection container, enabling automatic instance creation and injection where needed.

B It automatically binds the class to HTTP routes based on method names.

C It disables the class from being injected anywhere to prevent circular dependencies.

D It converts the class into a global singleton accessible without importing.

💡 Hint

Focus on how NestJS manages class instances and sharing.

The @Injectable() decorator marks a class as a provider so NestJS can create and inject instances automatically. It does not bind routes or disable injection.

Practice

1. What is the main purpose of the @Injectable() decorator in NestJS?

easy

A. To style components with CSS

B. To define a route handler in a controller

C. To create a database connection automatically

D. To mark a class so NestJS can manage it for dependency injection

Solution

1. Step 1: Understand the role of @Injectable()

   This decorator tells NestJS that the class can be injected as a dependency, making it reusable and manageable by the framework.

2. Step 2: Differentiate from other decorators

   Other decorators like @Controller() or database decorators serve different purposes, not dependency injection.

3. Final Answer:

   To mark a class so NestJS can manage it for dependency injection -> Option D

4. Quick Check:

   @Injectable() = marks class for DI [OK]

Hint: Remember: @Injectable() means NestJS manages the class [OK]

Common Mistakes:

• Confusing @Injectable() with @Controller()
• Thinking it creates routes or database connections
• Assuming it styles components

2. Which of the following is the correct syntax to make a service class injectable in NestJS?

easy

A. function Injectable() { return class MyService {} }

B. class MyService {}

C. @Injectable() class MyService {}

D. @Injectable class MyService {}

Solution

1. Step 1: Recall correct decorator syntax

   In NestJS, decorators are functions called with parentheses, so @Injectable() is correct.

2. Step 2: Check each option

   class MyService {} lacks the decorator. function Injectable() { return class MyService {} } is invalid syntax. @Injectable class MyService {} misses parentheses after @Injectable.

3. Final Answer:

   @Injectable() class MyService {} -> Option C

4. Quick Check:

   Decorator syntax requires parentheses () [OK]

Hint: Always use parentheses with decorators like @Injectable() [OK]

Common Mistakes:

• Omitting parentheses after @Injectable
• Trying to use @Injectable without decorator syntax
• Confusing class and function syntax

3. Given the following code, what will be the output when appService.getMessage() is called?

import { Injectable } from '@nestjs/common';

@Injectable()
class AppService {
  getMessage() {
    return 'Hello from AppService';
  }
}

const appService = new AppService();
console.log(appService.getMessage());

medium

A. Hello from AppService

B. undefined

C. Error: AppService is not injectable

D. null

Solution

1. Step 1: Understand @Injectable() effect on class instantiation

   The @Injectable() decorator marks the class for NestJS DI but does not change normal instantiation behavior.

2. Step 2: Analyze the code execution

   The code creates an instance manually and calls getMessage(), which returns the string as expected.

3. Final Answer:

   Hello from AppService -> Option A

4. Quick Check:

   Manual instantiation still works; method returns string [OK]

Hint: Manual new works; decorator doesn't block normal class use [OK]

Common Mistakes:

• Assuming decorator breaks manual instantiation
• Expecting an error without NestJS container
• Thinking method returns undefined

4. Identify the error in this NestJS service code:

import { Injectable } from '@nestjs/common';

@Injectable
export class UserService {
  getUser() {
    return 'User data';
  }
}

medium

A. Missing parentheses after @Injectable decorator

B. Class name should be lowercase

C. Method getUser must be async

D. Missing export keyword

Solution

1. Step 1: Check decorator syntax

   The @Injectable decorator must be called with parentheses: @Injectable().

2. Step 2: Verify other code parts

   Class name casing is correct by convention. Method need not be async. Export keyword is present.

3. Final Answer:

   Missing parentheses after @Injectable decorator -> Option A

4. Quick Check:

   Decorator requires () to work properly [OK]

Hint: Always add () after decorators like @Injectable() [OK]

Common Mistakes:

• Forgetting parentheses after decorator
• Thinking method must be async
• Confusing export keyword presence

5. You want to create a reusable logging service in NestJS that other services can inject. Which of the following is the best way to define it?

hard

A. Create a class without @Injectable() and instantiate it manually everywhere

B. Use @Injectable() on the logging class and inject it where needed

C. Define logging functions in a plain JavaScript object and export it

D. Use @Controller() decorator on the logging class

Solution

1. Step 1: Understand dependency injection benefits

   Using @Injectable() allows NestJS to manage the logging service lifecycle and inject it automatically where needed.

2. Step 2: Evaluate options for reusability and testability

   Manual instantiation loses DI benefits. Plain objects lack lifecycle and DI. @Controller() is for routing, not services.

3. Final Answer:

   Use @Injectable() on the logging class and inject it where needed -> Option B

4. Quick Check:

   Injectable services = reusable and testable [OK]

Hint: Always use @Injectable() for reusable NestJS services [OK]

Common Mistakes:

• Skipping @Injectable() and instantiating manually
• Using @Controller() for services
• Using plain objects without DI benefits