Showing validation errors in Angular - Deep Dive

Overview - Showing validation errors

What is it?

Showing validation errors means displaying messages to users when their input in a form is incorrect or missing. In Angular, this helps users know what they need to fix before submitting a form. It usually happens in real-time or after trying to submit. This improves user experience by guiding them to enter valid information.

Why it matters

Without showing validation errors, users would not know why their form submission failed or what to correct. This can cause frustration, mistakes, and abandoned forms. Validation errors make forms friendlier and reduce errors in data collection, which is important for websites and apps that rely on user input.

Where it fits

Before learning this, you should understand Angular forms basics, including template-driven or reactive forms and how to bind form controls. After this, you can learn about custom validators, async validation, and advanced form handling techniques.

Mental Model

Core Idea

Validation errors are feedback messages that tell users exactly what is wrong with their input so they can fix it.

Think of it like...

It's like a teacher marking your homework with red ink and writing notes on what needs correction so you can improve.

Form Input Field
┌─────────────────────┐
│ [User types here]   │
└─────────────────────┘
         ↓
Validation Check → If invalid → Show error message below

Example:
[Email Input]  
Invalid email format

Build-Up - 6 Steps

1

Foundation

Basic form control validation

Concept: Learn how Angular tracks form control states and built-in validators.

Angular forms have controls that hold user input and track their state like valid, invalid, touched, or dirty. Built-in validators like required, minlength, and pattern check if input meets rules. You add validators to controls in your form setup.

Result

Angular knows if each input is valid or not and updates the form state accordingly.

Understanding how Angular tracks control states is key to knowing when and what validation errors to show.

2

Foundation

Displaying error messages in template

Concept: Show error messages conditionally based on control state and errors.

In the template, you check if a control is invalid and touched or dirty. Then you display messages for each error type. For example, if the 'required' error exists, show 'This field is required'. Use *ngIf to conditionally show messages.

Result

Users see clear messages telling them what is wrong with their input after interacting with the field.

Displaying errors only after user interaction prevents overwhelming users with messages before they start typing.

3

Intermediate

Using reactive forms for validation errors

🤔Before reading on: Do you think reactive forms handle validation errors differently than template-driven forms? Commit to your answer.

Concept: Reactive forms use explicit form control objects in the component class, making validation error handling more predictable and testable.

In reactive forms, you create FormControl or FormGroup instances in the component. You add validators when creating controls. In the template, you access control.errors and control.touched to show messages. This approach separates logic from template.

Result

Validation errors are managed in the component class, making complex validation easier to handle and test.

Knowing reactive forms separate validation logic from the template helps build scalable and maintainable forms.

4

Intermediate

Custom validation error messages

🤔Before reading on: Can you guess how to show different messages for different validation errors on the same field? Commit to your answer.

Concept: You can check for specific error keys on a control and show tailored messages for each error type.

Each validator adds a key to the control.errors object when invalid. For example, 'required', 'minlength', or 'pattern'. In the template, use *ngIf to check for each key and display a specific message. This gives users precise feedback.

Result

Users get detailed guidance on what exactly is wrong with their input.

Understanding error keys lets you create user-friendly messages that improve form usability.

5

Advanced

Showing errors only after submit attempt

🤔Before reading on: Should validation errors always show immediately or only after trying to submit? Commit to your answer.

Concept: Sometimes you want to show errors only after the user tries to submit the form to avoid distraction.

You can track a 'submitted' flag in your component. In the template, show errors if the control is invalid and either touched or the form is submitted. This balances helpful feedback with less noise.

Result

Users see errors only when relevant, improving experience especially on large forms.

Knowing when to show errors prevents overwhelming users and reduces frustration.

6

Expert

Handling async validation errors gracefully

🤔Before reading on: Do you think async validators behave the same as sync ones for showing errors? Commit to your answer.

Concept: Async validators run in the background and can add errors after some delay, requiring special handling in the UI.

Async validators return a Promise or Observable. Angular sets control.pending while waiting. You can show a loading indicator during this time. Once complete, errors appear in control.errors. Your template should handle pending state and show errors only after completion.

Result

Users get clear feedback even when validation depends on server checks, like username availability.

Understanding async validation states helps avoid confusing UI flickers and improves user trust.

Under the Hood

Angular forms create FormControl objects that track value, state, and errors. Validators are functions that run on the control's value and return error objects or null. Angular runs validators on value changes and updates control.errors. The template binds to these states to show or hide messages dynamically.

Why designed this way?

This design separates validation logic from UI, making forms reactive and efficient. It allows Angular to update only what changes, improving performance and user experience. The error object pattern supports multiple errors per control and easy message mapping.

┌───────────────┐
│ User Input    │
└──────┬────────┘
       │ updates
┌──────▼────────┐
│ FormControl   │
│ - value      │
│ - status     │
│ - errors     │
└──────┬────────┘
       │ runs validators
┌──────▼────────┐
│ Validators   │
│ (sync/async) │
└──────┬────────┘
       │ returns errors/null
┌──────▼────────┐
│ Update errors │
│ in FormControl│
└──────┬────────┘
       │ template reads
┌──────▼────────┐
│ Show messages │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think validation errors should always show immediately as the user types? Commit yes or no.

Common Belief: Validation errors should appear instantly as soon as the user starts typing.

Reality: Showing errors immediately can annoy users and cause confusion; it's better to show errors after the user leaves the field or tries to submit.

Why it matters: Showing errors too early can make users feel overwhelmed and may cause them to abandon the form.

Quick: Do you think Angular automatically shows validation error messages without template code? Commit yes or no.

Common Belief: Angular automatically displays validation error messages for invalid inputs.

Reality: Angular only tracks validation states; developers must write template code to display error messages explicitly.

Why it matters: Assuming errors show automatically leads to forms that fail silently, confusing users.

Quick: Do you think async validators block form submission until complete? Commit yes or no.

Common Belief: Async validators block the form submission until they finish validating.

Reality: Async validators run in the background; the form can be submitted before they complete unless you check their status explicitly.

Why it matters: Ignoring async validation states can cause invalid data to be submitted or confusing UI behavior.

Quick: Do you think all validation errors are stored as strings? Commit yes or no.

Common Belief: Validation errors are simple strings describing the problem.

Reality: Validation errors are objects with keys and sometimes extra info, allowing multiple errors and detailed messages.

Why it matters: Misunderstanding error structure limits the ability to show precise messages and handle complex validation.

Expert Zone

1

Angular's control.errors object can hold multiple errors simultaneously, requiring careful template logic to avoid message clutter.

2

Async validators can cause flickering error messages if the UI does not handle the pending state properly.

3

Custom validators can return complex error objects, enabling dynamic messages but requiring consistent error key naming.

When NOT to use

Showing validation errors is essential for user input forms, but in some cases like read-only forms or display-only data, validation errors are unnecessary. For very simple forms, minimal validation with native HTML5 attributes might suffice instead of Angular validation.

Production Patterns

In production, developers often combine reactive forms with centralized error message services to keep templates clean. They also use form submission flags to control error display and implement async validation for server-side checks like username uniqueness.

Connections

User Experience Design

Builds-on

Understanding how to show validation errors well directly improves user experience by reducing frustration and guiding users smoothly.

State Management

Same pattern

Validation error handling in Angular forms is a form of state management, tracking input validity and user interaction states.

Error Handling in Software Engineering

Builds-on

Showing validation errors is a user-facing example of error handling, teaching how to detect, report, and recover from errors gracefully.

Common Pitfalls

#1 Showing validation errors before user interacts with the form field.

Wrong approach:

Invalid email

Correct approach:

Invalid email

Root cause:

Not checking user interaction state causes errors to show immediately, annoying users.

#2 Not handling async validator pending state, causing flickering messages.

Wrong approach:

Username taken

Correct approach:

Checking availability...

Username taken

Root cause:

Ignoring pending state causes error messages to appear and disappear unpredictably.

#3 Assuming Angular shows error messages automatically without template code.

Wrong approach:

Correct approach:

Name is required

Root cause:

Misunderstanding that Angular only tracks validation state but does not display messages.

Key Takeaways

Showing validation errors guides users to fix input mistakes, improving form usability and data quality.

Angular tracks form control states and errors, but developers must write template code to display messages conditionally.

Validation errors should appear only after user interaction or form submission to avoid overwhelming users.

Reactive forms separate validation logic from templates, making error handling more scalable and testable.

Handling async validation states properly prevents confusing UI flickers and ensures accurate feedback.

Practice

1. In Angular, when should you show validation error messages for a form field?

easy

A. Only after the user has touched or changed the field and it is invalid

B. Immediately when the form loads, regardless of user interaction

C. Only after the form is submitted, ignoring field interaction

D. Always show errors even if the field is valid

Solution

1. Step 1: Understand user experience best practice

   Showing errors only after user interaction prevents confusion and clutter.

2. Step 2: Angular validation behavior

   Angular's touched or dirty flags help detect user interaction before showing errors.

3. Final Answer:

   Only after the user has touched or changed the field and it is invalid -> Option A

4. Quick Check:

   Show errors after user interaction = D [OK]

Hint: Show errors only when user touched and invalid [OK]

Common Mistakes:

• Showing errors immediately on page load
• Showing errors without checking if field is invalid
• Waiting only for form submit to show errors

2. Which Angular directive is used to check if a form control is invalid and touched in a template?

easy

A. *ngIf="myControl.invalid && myControl.touched"

B. *ngFor="let control of myControl.invalid"

C. *ngSwitchCase="myControl.valid"

D. *ngModel="myControl.errors"

Solution

1. Step 1: Identify Angular directives for conditionally showing elements

   *ngIf is used to conditionally display content based on an expression.

2. Step 2: Check correct condition for validation errors

   Use myControl.invalid && myControl.touched to show errors only when invalid and user touched the field.

3. Final Answer:

   *ngIf="myControl.invalid && myControl.touched" -> Option A

4. Quick Check:

   *ngIf with invalid and touched = A [OK]

Hint: Use *ngIf with invalid and touched to show errors [OK]

Common Mistakes:

• Using *ngFor instead of *ngIf for condition
• Checking valid instead of invalid
• Using *ngModel incorrectly for validation display

3. Given this Angular template snippet:

<input [formControl]="emailControl">
<div *ngIf="emailControl.invalid && emailControl.touched">
  <small *ngIf="emailControl.errors?.required">Email is required.</small>
  <small *ngIf="emailControl.errors?.email">Invalid email format.</small>
</div>

What will be shown if the user focuses and leaves the input empty?

medium

A. The message 'Invalid email format.' will be displayed

B. No message will be displayed because the field is empty

C. The message 'Email is required.' will be displayed

D. Both messages will be displayed

Solution

1. Step 1: Analyze validation conditions

   The input is empty and touched, so required error is true, but email error is false because empty triggers required first.

2. Step 2: Determine which message shows

   Only the required error message is shown because emailControl.errors?.required is true.

3. Final Answer:

   The message 'Email is required.' will be displayed -> Option C

4. Quick Check:

   Empty + touched triggers required error = B [OK]

Hint: Empty touched field triggers required error message [OK]

Common Mistakes:

• Assuming invalid email message shows on empty input
• Showing no message on touched empty field
• Showing both messages simultaneously

4. You wrote this Angular code to show a required error:

<div *ngIf="emailControl.errors.required">Email is required.</div>

But the error never shows even when the field is empty and touched. What is the likely problem?

medium

A. You need to add Validators.email to the control

B. You forgot to check if the control is touched before showing errors

C. You should use emailControl.invalid instead of emailControl.errors.required

D. You must use ngModel instead of formControl

Solution

1. Step 1: Understand when errors should show

   Errors should show only after user interaction, so checking touched is important.

2. Step 2: Identify missing condition

   The code only checks errors.required but not if the user touched the field, so error stays hidden initially.

3. Final Answer:

   You forgot to check if the control is touched before showing errors -> Option B

4. Quick Check:

   Check touched before errors to show messages = C [OK]

Hint: Always check touched before showing validation errors [OK]

Common Mistakes:

• Showing errors without user interaction check
• Confusing invalid with errors property
• Adding unrelated validators like email for required error

5. You want to show validation errors for a password field only if the user has interacted with it and it is invalid. You also want to show a custom message if the password is less than 8 characters. Which Angular template snippet correctly implements this?

hard

A. <input type="password" [formControl]="passwordControl">
<div *ngIf="passwordControl.invalid">
<small *ngIf="passwordControl.errors?.minlength">Password must be at least 8 characters.</small>
</div>

B. <input type="password" [formControl]="passwordControl">
<div *ngIf="passwordControl.errors?.minlength">
<small>Password must be at least 8 characters.</small>
</div>

C. <input type="password" [formControl]="passwordControl">
<div *ngIf="passwordControl.touched">
<small *ngIf="passwordControl.errors?.minlength">Password must be at least 8 characters.</small>
</div>

D. <input type="password" [formControl]="passwordControl">
<div *ngIf="passwordControl.invalid && passwordControl.touched">
<small *ngIf="passwordControl.errors?.minlength">Password must be at least 8 characters.</small>
</div>

Solution

1. Step 1: Ensure errors show only after user interaction

   Check both invalid and touched to avoid showing errors prematurely.

2. Step 2: Show specific minlength error message

   Use passwordControl.errors?.minlength inside the conditional block to display the custom message.

3. Final Answer:

   Correctly combines invalid, touched, and minlength error check -> Option D

4. Quick Check:

   Check invalid and touched with minlength error = A [OK]

Hint: Combine invalid and touched to show specific error messages [OK]

Common Mistakes:

• Showing errors without checking touched
• Showing errors on invalid without user interaction
• Missing specific error condition for minlength