Nested DTO validation in NestJS - Step-by-Step Execution

Concept Flow - Nested DTO validation

Receive Request with Nested Data

↓

Parse Outer DTO

↓

Validate Outer DTO Fields

↓

Parse Nested DTO

↓

Validate Nested DTO Fields

↓

If All Valid -> Proceed

No↓

Return Validation Errors

The flow shows how NestJS receives a request, parses the outer DTO, then parses and validates nested DTOs before proceeding or returning errors.

Execution Sample

NestJS

import { IsString, ValidateNested } from 'class-validator';
import { Type } from 'class-transformer';

class AddressDto {
  @IsString()
  street: string;
}

class UserDto {
  @IsString()
  name: string;

  @ValidateNested()
  @Type(() => AddressDto)
  address: AddressDto;
}

Defines UserDto with a nested AddressDto, both validated for correct types.

Execution Table

Step	Action	Data Being Validated	Validation Result	Next Step
1	Receive request body	{"name":"Alice","address":{"street":"Main St"}}	N/A	Parse UserDto
2	Validate UserDto.name	"Alice"	Valid	Parse Nested AddressDto
3	Validate AddressDto.street	"Main St"	Valid	All Valid - Proceed
4	Return success	N/A	N/A	End

💡 Validation passes for all nested DTO fields, request proceeds.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
name	undefined	"Alice"	"Alice"	"Alice"
address.street	undefined	undefined	"Main St"	"Main St"

Key Moments - 2 Insights

Why do we need @ValidateNested() and @Type() decorators on nested DTOs?

Because without @ValidateNested(), the nested object won't be validated. @Type() tells class-transformer how to convert plain object to the nested DTO class. See execution_table steps 2 and 3 where nested validation happens.

What happens if nested DTO fields are missing or invalid?

Validation fails at the nested DTO step (step 3 in execution_table), and the request returns validation errors instead of proceeding.

Visual Quiz - 3 Questions

Look at the execution_table, what is validated at step 3?

A UserDto.name field

B Entire request body as a string

C AddressDto.street field

D No validation at this step

💡 Hint

Check the 'Data Being Validated' column at step 3 in execution_table.

At which step does the nested DTO validation occur?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look for 'Validate AddressDto.street' in the execution_table.

If the 'address' field was missing in the request, what would happen?

A Validation would pass because nested DTO is optional

B Validation would fail at nested DTO validation step

C Validation would fail at UserDto.name validation

D Request would be accepted without errors

💡 Hint

Refer to key_moments about missing nested DTO fields causing validation failure.

Concept Snapshot

Nested DTO Validation in NestJS:
- Use @ValidateNested() on nested DTO properties
- Use @Type(() => NestedDto) for proper transformation
- Outer DTO validates first, then nested DTOs
- Validation errors stop request processing
- Ensures deep validation of complex objects

Full Transcript

This visual execution shows how NestJS validates nested DTOs step-by-step. First, the request body is received and parsed into the outer DTO. Then, the outer DTO fields are validated. Next, the nested DTO is parsed and validated using @ValidateNested and @Type decorators. If all validations pass, the request proceeds. If any validation fails, errors are returned. This ensures that nested objects are properly checked for correctness, preventing invalid data from entering the system.

Practice

1. What is the main purpose of using @ValidateNested() in a NestJS DTO?

easy

A. To define default values for nested properties

B. To convert nested objects to plain JavaScript objects

C. To skip validation of nested objects

D. To validate properties of nested objects inside the DTO automatically

Solution

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

   This decorator tells NestJS to validate nested objects inside a DTO, not just the top-level properties.

2. Step 2: Compare with other options

   @Type() handles transformation, not validation. Skipping validation or setting defaults is unrelated to @ValidateNested().

3. Final Answer:

   To validate properties of nested objects inside the DTO automatically -> Option D

4. Quick Check:

   @ValidateNested() = validate nested objects [OK]

Hint: Remember: @ValidateNested() triggers nested object validation [OK]

Common Mistakes:

• Confusing @ValidateNested() with @Type()
• Thinking it skips validation
• Assuming it sets default values

2. Which of the following is the correct way to apply nested validation in a DTO property?

easy

A. Use both @ValidateNested() and @Type(() => NestedDto)

B. Use @ValidateNested() only

C. Use @Type(() => NestedDto) only

D. Use @IsString() on the nested property

Solution

1. Step 1: Identify decorators needed for nested validation

   @ValidateNested() triggers validation of nested objects, but @Type() is needed to transform plain objects into class instances.

2. Step 2: Understand why both are required

   Without @Type(), validation won't work properly because the nested object won't be recognized as the correct class type.

3. Final Answer:

   Use both @ValidateNested() and @Type(() => NestedDto) -> Option A

4. Quick Check:

   Nested validation = @ValidateNested() + @Type() [OK]

Hint: Always pair @ValidateNested() with @Type() for nested DTOs [OK]

Common Mistakes:

• Using only one decorator and expecting full validation
• Applying @IsString() on an object property
• Forgetting to import Type from class-transformer

3. Given the following DTOs, what will happen if address.zipCode is missing when validating UserDto?

class AddressDto {
  @IsString()
  street: string;

  @IsString()
  zipCode: string;
}

class UserDto {
  @IsString()
  name: string;

  @ValidateNested()
  @Type(() => AddressDto)
  address: AddressDto;
}

medium

A. Validation will fail because zipCode is missing

B. Validation will pass because zipCode is optional

C. Validation will fail because name is missing

D. Validation will pass but address will be undefined

Solution

1. Step 1: Check required properties in AddressDto

   Both street and zipCode are decorated with @IsString(), so they are required and must be strings.

2. Step 2: Understand nested validation in UserDto

   @ValidateNested() with @Type() ensures address is validated as AddressDto, so missing zipCode causes validation to fail.

3. Final Answer:

   Validation will fail because zipCode is missing -> Option A

4. Quick Check:

   Missing required nested property = validation fails [OK]

Hint: Missing required nested fields cause validation failure [OK]

Common Mistakes:

• Assuming missing nested fields are allowed by default
• Ignoring the effect of @ValidateNested()
• Confusing missing nested fields with missing top-level fields

4. Consider this DTO code snippet:

class ProfileDto {
  @IsString()
  bio: string;
}

class UserDto {
  @IsString()
  username: string;

  @ValidateNested()
  profile: ProfileDto;
}

Why will validation NOT work correctly for the nested profile property?

medium

A. Because @ValidateNested() should be on ProfileDto class

B. Because @IsString() is missing on profile

C. Because @Type(() => ProfileDto) decorator is missing on profile

D. Because bio property is missing @ValidateNested()

Solution

1. Step 1: Identify missing decorator for nested validation

   For nested validation to work, @Type(() => ProfileDto) must be added to the nested property to transform plain objects into class instances.

2. Step 2: Understand why other options are incorrect

   @IsString() is for string properties, not objects. @ValidateNested() belongs on the nested property, not the nested class. bio is a string, no nested validation needed.

3. Final Answer:

   Because @Type(() => ProfileDto) decorator is missing on profile -> Option C

4. Quick Check:

   Missing @Type() breaks nested validation [OK]

Hint: Always add @Type() with @ValidateNested() for nested DTOs [OK]

Common Mistakes:

• Forgetting @Type() on nested properties
• Misplacing @ValidateNested() on nested class
• Confusing property decorators with class decorators

5. You have a CompanyDto with a nested array of EmployeeDto objects. Which is the correct way to validate this nested array properly?

class EmployeeDto {
  @IsString()
  name: string;

  @IsInt()
  age: number;
}

class CompanyDto {
  @IsString()
  companyName: string;

  @ValidateNested({ each: true })
  @Type(() => EmployeeDto)
  employees: EmployeeDto[];
}

hard

A. You must remove { each: true } from @ValidateNested() for arrays

B. This setup correctly validates each employee in the employees array

C. You should use @IsArray() instead of @ValidateNested() for employees

D. You need to add @IsOptional() to employees to validate nested arrays

Solution

1. Step 1: Understand nested array validation

   For arrays of nested objects, @ValidateNested({ each: true }) tells the validator to check each item in the array.

2. Step 2: Confirm use of @Type() for transformation

   @Type(() => EmployeeDto) converts plain objects to EmployeeDto instances, enabling validation on each employee.

3. Final Answer:

   This setup correctly validates each employee in the employees array -> Option B

4. Quick Check:

   Nested arrays need @ValidateNested({ each: true }) + @Type() [OK]

Hint: Use { each: true } with @ValidateNested() for nested arrays [OK]

Common Mistakes:

• Omitting { each: true } for arrays
• Using @IsArray() alone without nested validation
• Forgetting @Type() for nested array items