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.