Nested DTO validation in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output when validating nested DTOs with missing required fields?

Consider the following NestJS DTOs with validation decorators. What will happen if the nested object is missing a required field?

NestJS

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

class AddressDto {
  @IsString()
  street: string;

  @IsString()
  city: string;
}

class UserDto {
  @IsString()
  name: string;

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

// Input object:
const input = {
  name: 'Alice',
  address: {
    city: 'Wonderland'
  }
};

// What happens when validating input against UserDto?

A Validation fails because 'street' is missing in the nested AddressDto.

B Validation passes because only the top-level fields are checked.

C Validation fails because 'name' is missing, even though it is present.

D Validation passes because nested validation decorators are ignored by default.

💡 Hint

Think about how @ValidateNested() and @Type() work together to validate nested objects.

The @ValidateNested() decorator tells NestJS to validate the nested object. The @Type(() => AddressDto) decorator ensures the nested plain object is transformed into an instance of AddressDto. Since street is required and missing, validation fails.

📝 Syntax

intermediate

Which option correctly applies nested DTO validation in NestJS?

Given two DTO classes, which code snippet correctly applies nested validation so that the nested object is validated?

NestJS

class ChildDto {
  @IsString()
  childProp: string;
}

class ParentDto {
  @IsString()
  parentProp: string;

  // What decorators should be here for nested validation?
  nested: ChildDto;
}

A

@ValidateIf(o => o.nested)
@IsString()
nested: ChildDto;

B

@IsObject()
@ValidateNested({ each: true })
nested: ChildDto;

C

@ValidateNested()
@Type(() => ChildDto)
nested: ChildDto;

D

@IsDefined()
@Type(() => ChildDto)
nested: ChildDto;

💡 Hint

Remember that @ValidateNested() triggers validation of nested objects and @Type() transforms plain objects to class instances.

Option C correctly uses @ValidateNested() to validate the nested object and @Type(() => ChildDto) to transform the plain object into a ChildDto instance. Other options either misuse decorators or miss transformation.

🔧 Debug

advanced

Why does nested DTO validation not trigger for an array of nested objects?

Given this DTO, why does validation not run on the nested array items?

NestJS

class ItemDto {
  @IsString()
  name: string;
}

class ContainerDto {
  @ValidateNested({ each: true })
  @Type(() => ItemDto)
  items: ItemDto[];
}

// Input:
const input = { items: [{ name: 'Item1' }, { name: 123 }] };

// Validation is run on ContainerDto with input. Why does the invalid second item not cause an error?

A Because @ValidateNested({ each: true }) is ignored on arrays.

B Because the input array items are not transformed to ItemDto instances before validation.

C Because @Type(() => ItemDto) only works on single objects, not arrays.

D Because the validation pipe is missing in the controller.

💡 Hint

Think about how class-transformer transforms arrays of objects.

By default, class-transformer does not transform array items unless the validation pipe is configured with transform: true. Without transformation, nested validation does not run on plain objects inside arrays.

❓ state_output

advanced

What is the validation error output for deeply nested DTOs with missing fields?

Given these nested DTOs, what validation error message will be produced if the deepest nested field is missing?

NestJS

class Level3Dto {
  @IsString()
  detail: string;
}

class Level2Dto {
  @ValidateNested()
  @Type(() => Level3Dto)
  level3: Level3Dto;
}

class Level1Dto {
  @ValidateNested()
  @Type(() => Level2Dto)
  level2: Level2Dto;
}

const input = { level2: { level3: {} } };

// After validating input against Level1Dto, what error appears?

A [{"property":"level3","constraints":{"isString":"detail must be a string"}}]

B No validation errors because nested validation stops at level2.

C [{"property":"level2","constraints":{"isDefined":"level2 should not be null or undefined"}}]

D [{"property":"level2","children":[{"property":"level3","children":[{"property":"detail","constraints":{"isString":"detail must be a string"}}]}]}]

💡 Hint

Consider how validation errors are nested and reported for nested DTOs.

Validation errors for nested DTOs are nested inside the children array of the parent property. Since detail is missing and required, the error appears nested inside level2 and level3.

🧠 Conceptual

expert

Why is the @Type decorator essential for nested DTO validation in NestJS?

In NestJS, why must you use the @Type(() => NestedDto) decorator alongside @ValidateNested() for nested DTO validation?

A Because @Type transforms plain objects into class instances, enabling class-validator to run validation decorators on nested DTOs.

B Because @Type automatically validates nested DTOs without needing @ValidateNested().

C Because @Type disables validation on nested DTOs to improve performance.

D Because @Type is required to serialize nested DTOs to JSON after validation.

💡 Hint

Think about how class-transformer and class-validator work together in NestJS.

The @Type() decorator tells class-transformer how to convert plain nested objects into instances of the nested DTO class. Without this transformation, class-validator cannot apply validation decorators on nested properties because they are plain objects, not class instances.

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