DTO class creation in NestJS - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does DTO stand for in NestJS?

DTO stands for Data Transfer Object. It is a simple object used to carry data between processes or layers in an application.

beginner

Why do we use DTO classes in NestJS?

We use DTO classes to define how data should be sent or received. They help validate and type-check data, making the app safer and easier to maintain.

beginner

How do you create a simple DTO class in NestJS?

You create a class with properties that match the data you expect. For example:<br><pre>export class CreateUserDto {
  name: string;
  age: number;
}</pre>

intermediate

What decorator is commonly used with DTO properties for validation in NestJS?

Decorators from the class-validator package like @IsString(), @IsInt(), and @IsNotEmpty() are used to validate DTO properties.

intermediate

How does NestJS use DTO classes in controllers?

NestJS uses DTO classes to type-check and validate incoming request data automatically when you use them as method parameters with decorators like @Body().

What is the main purpose of a DTO class in NestJS?

A To define the shape of data sent or received

B To handle database queries

C To create UI components

D To manage server configuration

DTO classes define how data should look when sent or received, helping with validation and type safety.

Which package provides decorators like @IsString() for DTO validation?

A class-transformer

B nestjs/common

C rxjs

D class-validator

The class-validator package provides decorators to validate DTO properties.

How do you apply a DTO class to validate incoming data in a NestJS controller?

A Use @Body() decorator with the DTO class as type

B Use @Param() decorator

C Use @Injectable() decorator

D Use @Get() decorator

You use the @Body() decorator and specify the DTO class type to validate incoming request body data.

Which of these is a valid DTO property declaration in NestJS?

A function name() {}

B name: string;

C const name = 'string';

D let name: string = '';

DTO properties are declared as class properties with types, like 'name: string;'.

What happens if incoming data does not match the DTO validation rules?

A The request is accepted without changes

B The server restarts

C NestJS throws a validation error and rejects the request

D The data is automatically corrected

NestJS rejects requests with invalid data by throwing validation errors when DTO validation fails.

Explain what a DTO class is and why it is useful in NestJS applications.

Think about how data moves between client and server and how to keep it safe and clear.

Describe the steps to create and use a DTO class for validating user input in a NestJS controller.

Focus on class creation, decorators, and controller usage.

Practice

1. What is the main purpose of a DTO class in a NestJS application?

easy

A. To handle database connections and queries

B. To create UI components for the frontend

C. To define the shape and validation rules of data transferred between layers

D. To manage application routing and middleware

Solution

1. Step 1: Understand the role of DTOs

   DTO stands for Data Transfer Object, used to define how data should look when sent or received.

2. Step 2: Identify what DTOs do in NestJS

   In NestJS, DTOs specify the structure and validation of data between client and server or between app layers.

3. Final Answer:

   To define the shape and validation rules of data transferred between layers -> Option C

4. Quick Check:

   DTO = Data shape and validation [OK]

Hint: DTOs organize and validate data structure in NestJS [OK]

Common Mistakes:

• Confusing DTOs with database models
• Thinking DTOs handle routing or UI
• Assuming DTOs manage middleware

2. Which of the following is the correct way to declare a required string property name in a NestJS DTO class using class-validator decorators?

easy

A. @IsString() name: string;

B. name: string;

C. @IsOptional() name: string;

D. @IsNumber() name: string;

Solution

1. Step 1: Identify the decorator for string validation

   The @IsString() decorator from class-validator ensures the property is a string and required by default.

2. Step 2: Check other options

   name: string; lacks validation, C marks it optional, and D wrongly uses number validation.

3. Final Answer:

   @IsString() name: string; -> Option A

4. Quick Check:

   Use @IsString() for required string fields [OK]

Hint: Use @IsString() to require string fields in DTOs [OK]

Common Mistakes:

• Omitting validation decorators
• Using @IsOptional() for required fields
• Applying wrong type decorators like @IsNumber()

3. Given this DTO class, what will be the result of validating an object { name: "Alice", age: 25 }?

import { IsString, IsInt, IsOptional } from 'class-validator';

export class UserDto {
  @IsString()
  name: string;

  @IsInt()
  @IsOptional()
  age?: number;
}

medium

A. Validation passes because name is string and age is optional integer

B. Validation fails because age is required but missing

C. Validation fails because name is not optional

D. Validation passes only if age is a string

Solution

1. Step 1: Analyze the DTO decorators

   Name is required string, age is optional integer due to @IsOptional() and @IsInt().

2. Step 2: Check the input object

   Input has name as string "Alice" and age as number 25, matching the DTO rules.

3. Final Answer:

   Validation passes because name is string and age is optional integer -> Option A

4. Quick Check:

   Required string + optional int with valid data = pass [OK]

Hint: Optional fields pass validation if present and valid [OK]

Common Mistakes:

• Assuming optional fields must be present
• Confusing @IsOptional() effect
• Thinking validation fails if optional field is present

4. Identify the error in this DTO class that causes validation to always fail for the email property:

import { IsEmail } from 'class-validator';

export class EmailDto {
  @IsEmail
  email: string;
}

medium

A. Should import IsString instead of IsEmail

B. email property should be optional

C. email property type should be number

D. Missing parentheses after @IsEmail decorator

Solution

1. Step 1: Check decorator usage

   @IsEmail is a function decorator and must be called with parentheses: @IsEmail()

2. Step 2: Understand effect of missing parentheses

   Without parentheses, the decorator is not applied properly, causing validation to fail.

3. Final Answer:

   Missing parentheses after @IsEmail decorator -> Option D

4. Quick Check:

   Decorators need () even if no args [OK]

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

Common Mistakes:

• Forgetting parentheses on decorators
• Changing property type incorrectly
• Using wrong decorators for email

5. You want to create a DTO class CreateProductDto with these rules:
- title is a required string
- price is a required positive number
- description is an optional string
Which of the following DTO class definitions correctly implements these rules?

hard

A. import { IsString, IsNumber, IsPositive, IsOptional } from 'class-validator';

export class CreateProductDto {
@IsString()
title?: string;

@IsNumber()
@IsPositive()
price?: number;

@IsOptional()
@IsString()
description?: string;
}

B. import { IsString, IsNumber, IsPositive, IsOptional } from 'class-validator';

export class CreateProductDto {
@IsString()
title: string;

@IsNumber()
@IsPositive()
price: number;

@IsOptional()
@IsString()
description?: string;
}

C. import { IsString, IsNumber, IsPositive } from 'class-validator';

export class CreateProductDto {
@IsString()
title: string;

@IsNumber()
price: number;

@IsString()
description: string;
}

D. import { IsString, IsNumber, IsPositive, IsOptional } from 'class-validator';

export class CreateProductDto {
@IsString()
title: string;

@IsNumber()
price: number;

@IsOptional()
description?: string;
}

Solution

1. Step 1: Check required string property

   Title is required string, so @IsString() with no @IsOptional() is correct.

2. Step 2: Check required positive number property

   Price must be number and positive, so @IsNumber() and @IsPositive() are needed without @IsOptional().

3. Step 3: Check optional string property

   Description is optional string, so @IsOptional() and @IsString() with optional property syntax (?) is correct.

4. Final Answer:

   DTO with @IsString() title, @IsNumber() + @IsPositive() price, and optional @IsOptional() description -> Option B

5. Quick Check:

   Required fields no @IsOptional(), optional fields with @IsOptional() [OK]

Hint: Use @IsOptional() only on optional fields [OK]

Common Mistakes:

• Marking required fields as optional
• Missing @IsPositive() for positive number
• Omitting @IsOptional() on optional fields