DEV Community: Olayinka Akeju

Testing Angular 21 Components with Vitest: A Complete Guide

Olayinka Akeju — Mon, 01 Dec 2025 12:08:07 +0000

Angular 21 replaced Karma with Vitest as the default testing framework. If you're used to Karma or Jest, this shift means new syntax, different patterns, and a fresh approach to testing, especially with Angular's signals and new control flow.

What You'll Learn

Setting up Vitest in Angular 21
Testing standalone components with signals and computed signals
Working with Angular's control flow syntax (@for, @if, @empty)
Understanding fixture.detectChanges() for DOM updates
Testing user interactions and edge cases

We're testing a full-featured task manager: add tasks, mark them complete, filter by status, and delete them. All code is on GitHub.

Project Setup

Angular 21 includes Vitest out of the box. Create a new project and you're ready to go:

ng new angular-vitest-testing-guide
cd angular-vitest-testing-guide

Verify Vitest is Installed

Check package.json:

{
  "devDependencies": {
    "@angular/build": "^21.0.0",
    "vitest": "^4.0.8"
  }
}

Check angular.json:

{
  "projects": {
    "your-project-name": {
      "architect": {
        "test": {
          "builder": "@angular/build:unit-test"
        }
      }
    }
  }
}

Run Tests

# Watch mode (default)
ng test

# Single run for CI
ng test --no-watch

Output should look like:

✓  angular-vitest-testing-guide  src/app/app.spec.ts (2 tests) 130ms
   ✓ App (2)
     ✓ should create the app 93ms
     ✓ should render title 35ms

 Test Files  1 passed (1)
      Tests  2 passed (2)

Optional: Code Coverage

Coverage needs an extra package:

npm install @vitest/coverage-v8 --save-dev
ng test --coverage

Coverage reports land in the coverage/ directory.

The Component We're Testing

The TaskList component handles everything you'd expect in a real task manager: adding tasks with validation, marking complete, filtering, and deleting. This mirrors production scenarios.

Features:

Add tasks (rejects empty/whitespace-only input)
Toggle completion status
Delete tasks
Filter by status (all, active, completed)
Clear all completed tasks
Show task counts
Display filter-specific empty states

Full component code on GitHub

Core implementation:

export class TaskListComponent {
  tasks = signal<Task[]>([]);
  filter = signal<TaskFilter>('all');

  // Computed signals auto-update when dependencies change
  activeTasksCount = computed(() =>
    this.tasks().filter(t => !t.completed).length
  );

  filteredTasks = computed(() => {
    switch (this.filter()) {
      case 'active': return this.tasks().filter(t => !t.completed);
      case 'completed': return this.tasks().filter(t => t.completed);
      default: return this.tasks();
    }
  });

  addTask() {
    const text = this.newTaskText().trim();
    if (!text) return;

    this.tasks.update(tasks => [...tasks, {
      id: Date.now(),
      text,
      completed: false,
      createdAt: new Date()
    }]);
    this.newTaskText.set('');
  }
}

Writing Your First Tests

Generate the component with its test file:

ng g c features/week-01-basics/task-list/components/task-list --type=component

Important: The --type=component flag adds the .component suffix and keeps Component in the class name. Without it, you get task-list.ts instead of task-list.component.ts, and TaskList instead of TaskListComponent.

Test File Structure

Basic Vitest setup for Angular components:

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { TaskListComponent } from './task-list.component';

describe('TaskListComponent', () => {
  let component: TaskListComponent;
  let fixture: ComponentFixture<TaskListComponent>;
  let compiled: HTMLElement;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [TaskListComponent] // Standalone = imports, not declarations
    }).compileComponents();

    fixture = TestBed.createComponent(TaskListComponent);
    component = fixture.componentInstance;
    compiled = fixture.nativeElement as HTMLElement;
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });
});

Key pieces:

ComponentFixture - Wrapper with testing utilities
component - Direct access to the TypeScript class
compiled - The actual rendered HTML
fixture.detectChanges() - Triggers change detection (more on this soon)

Testing Component Initialization

Verify the component starts in the correct state:

describe('Component Setup', () => {
  it('should create the component', () => {
    expect(component).toBeTruthy();
  });

  it('should initialize with empty tasks array', () => {
    expect(component.tasks()).toEqual([]);
  });

  it('should initialize with empty input text', () => {
    expect(component.newTaskText()).toBe('');
  });

  it('should initialize with "all" filter', () => {
    expect(component.filter()).toBe('all');
  });

  it('should display empty state message initially', () => {
    const emptyState = compiled.querySelector('[data-testid="empty-state"]');
    expect(emptyState).toBeTruthy();
    expect(emptyState?.textContent).toContain('No tasks yet');
  });
});

Testing Signals

Signals are functions, you call them to read, use .set() or .update() to write:

// Read a signal value
expect(component.tasks()).toEqual([]);

// Signals are just functions with ()
const currentTasks = component.tasks();
const currentFilter = component.filter();

Much simpler than Observables with their subscriptions and async complexity.

Testing User Interactions

Test the main feature: adding tasks.

describe('Adding Tasks', () => {
  it('should add a task with valid text', () => {
    // ARRANGE - Set up test data
    component.newTaskText.set('Go to the store');

    // ACT - Perform the action
    component.addTask();

    // ASSERT - Verify the result
    expect(component.tasks()).toHaveLength(1);
    expect(component.tasks()[0].text).toBe('Go to the store');
    expect(component.tasks()[0].completed).toBe(false);
  });

  it('should clear input after adding task', () => {
    component.newTaskText.set('Go to the store');
    component.addTask();

    expect(component.newTaskText()).toBe('');
  });

  it('should not add task with empty text', () => {
    component.newTaskText.set('');
    component.addTask();

    expect(component.tasks()).toHaveLength(0);
  });

  it('should not add task with whitespace-only text', () => {
    component.newTaskText.set('   ');
    component.addTask();

    expect(component.tasks()).toHaveLength(0);
  });

  it('should trim whitespace from task text', () => {
    component.newTaskText.set('  Go to the store  ');
    component.addTask();

    expect(component.tasks()[0].text).toBe('Go to the store');
  });
});

The AAA Pattern (Arrange, Act, Assert) makes tests self-documenting:

Arrange: Set up conditions
Act: Execute the action
Assert: Verify the outcome

Understanding fixture.detectChanges()

What Happens Without It

it('should display task in DOM after adding', () => {
  component.newTaskText.set('Go to the store');
  component.addTask();

  const taskItems = compiled.querySelectorAll('[data-testid^="task-item-"]');
  expect(taskItems).toHaveLength(1); // FAILS!
});

The component state updated (component.tasks() shows the task), but the DOM stayed empty. Why? Angular's change detection hasn't run yet.

The Fix

it('should display task in DOM after adding', () => {
  component.newTaskText.set('Go to the store');
  component.addTask();

  fixture.detectChanges(); // Trigger change detection

  const taskItems = compiled.querySelectorAll('[data-testid^="task-item-"]');
  expect(taskItems).toHaveLength(1); // Passes
  expect(taskItems[0].textContent).toContain('Go to the store');
});

The Rule

Call fixture.detectChanges() after state changes when testing DOM updates.

In real apps, Angular runs change detection automatically. In tests, you trigger it manually.

When to Use It

// YES - After state changes before checking DOM
component.addTask();
fixture.detectChanges();
const tasks = compiled.querySelectorAll('[data-testid^="task-item-"]');

// YES - After signal updates
component.filter.set('active');
fixture.detectChanges();

// YES - Already in beforeEach for initial render
beforeEach(async () => {
  fixture.detectChanges(); // Initial render
});

// NO - When testing component properties only
expect(component.tasks()).toHaveLength(1); // No DOM involved

Using data-testid for Reliable Tests

Notice our test queries use data-testid:

const taskItems = compiled.querySelectorAll('[data-testid^="task-item-"]');
const addButton = compiled.querySelector('[data-testid="add-button"]');

Why?

Unstable approach:

// Breaks when CSS changes
const button = compiled.querySelector('.btn-primary.add-task');

// Breaks when HTML structure changes
const task = compiled.querySelector('ul li:first-child');

Stable approach:

// Only changes when you intentionally update the test ID
const button = compiled.querySelector('[data-testid="add-button"]');

In Your Template

<!-- Static elements -->
<input data-testid="task-input" />
<button data-testid="add-button">Add</button>

<!-- Dynamic elements -->
<li [attr.data-testid]="'task-item-' + task.id">
  <input
    type="checkbox"
    [attr.data-testid]="'task-checkbox-' + task.id"
  />
</li>

This decouples tests from styling and structure, making them resilient to UI changes.

Testing Computed Signals

Computed signals auto-recalculate when dependencies change. Test this behavior:

describe('Computed Signals', () => {
  it('should calculate active tasks count correctly', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    component.newTaskText.set('Task 2');
    component.addTask();

    expect(component.activeTasksCount()).toBe(2);
    expect(component.completedTasksCount()).toBe(0);
  });

  it('should recalculate counts when task is toggled', () => {
    component.newTaskText.set('Task 1');
    component.addTask();

    expect(component.activeTasksCount()).toBe(1);
    expect(component.completedTasksCount()).toBe(0);

    // Toggle to completed
    const taskId = component.tasks()[0].id;
    component.toggleTask(taskId);

    expect(component.activeTasksCount()).toBe(0);
    expect(component.completedTasksCount()).toBe(1);
  });

  it('should update filtered tasks when filter changes', () => {
    component.newTaskText.set('Active Task');
    component.addTask();
    component.newTaskText.set('Completed Task');
    component.addTask();
    component.toggleTask(component.tasks()[1].id);

    component.setFilter('all');
    expect(component.filteredTasks()).toHaveLength(2);

    component.setFilter('active');
    expect(component.filteredTasks()).toHaveLength(1);
    expect(component.filteredTasks()[0].completed).toBe(false);

    component.setFilter('completed');
    expect(component.filteredTasks()).toHaveLength(1);
    expect(component.filteredTasks()[0].completed).toBe(true);
  });
});

Computed signals just work, no manual triggers needed:

const activeCount = component.activeTasksCount(); // Always current
const filtered = component.filteredTasks(); // Auto-filtered

Testing Task Toggling

describe('Toggling Tasks', () => {
  beforeEach(() => {
    component.newTaskText.set('Test task');
    component.addTask();
  });

  it('should mark task as completed', () => {
    const taskId = component.tasks()[0].id;
    component.toggleTask(taskId);

    expect(component.tasks()[0].completed).toBe(true);
  });

  it('should unmark completed task', () => {
    const taskId = component.tasks()[0].id;

    component.toggleTask(taskId); // Complete
    component.toggleTask(taskId); // Uncomplete

    expect(component.tasks()[0].completed).toBe(false);
  });

  it('should toggle correct task when multiple exist', () => {
    component.newTaskText.set('Second task');
    component.addTask();

    const secondTaskId = component.tasks()[1].id;
    component.toggleTask(secondTaskId);

    expect(component.tasks()[0].completed).toBe(false);
    expect(component.tasks()[1].completed).toBe(true);
  });

  it('should update DOM when task is toggled', () => {
    const taskId = component.tasks()[0].id;

    component.toggleTask(taskId);
    fixture.detectChanges();

    const checkbox = compiled.querySelector(
      `[data-testid="task-checkbox-${taskId}"]`
    ) as HTMLInputElement;

    expect(checkbox.checked).toBe(true);
  });
});

Note: The beforeEach inside this describe block runs before each test in this block, reducing repetition.

Testing Task Deletion

describe('Deleting Tasks', () => {
  it('should delete a task', () => {
    component.newTaskText.set('Task to delete');
    component.addTask();

    const taskId = component.tasks()[0].id;
    component.deleteTask(taskId);

    expect(component.tasks()).toHaveLength(0);
  });

  it('should delete correct task from list', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    component.newTaskText.set('Task 2');
    component.addTask();
    component.newTaskText.set('Task 3');
    component.addTask();

    const middleTaskId = component.tasks()[1].id;
    component.deleteTask(middleTaskId);

    expect(component.tasks()).toHaveLength(2);
    expect(component.tasks()[0].text).toBe('Task 1');
    expect(component.tasks()[1].text).toBe('Task 3');
  });

  it('should remove task from DOM', () => {
    component.newTaskText.set('Task to delete');
    component.addTask();
    fixture.detectChanges();

    const taskId = component.tasks()[0].id;
    component.deleteTask(taskId);
    fixture.detectChanges();

    const taskElement = compiled.querySelector(`[data-testid="task-item-${taskId}"]`);
    expect(taskElement).toBeNull();
  });
});

Testing Filters

describe('Filtering Tasks', () => {
  beforeEach(() => {
    component.newTaskText.set('Active 1');
    component.addTask();
    component.newTaskText.set('Completed 1');
    component.addTask();
    component.newTaskText.set('Active 2');
    component.addTask();

    component.toggleTask(component.tasks()[1].id);
  });

  it('should show all tasks by default', () => {
    expect(component.filter()).toBe('all');
    expect(component.filteredTasks()).toHaveLength(3);
  });

  it('should filter to active tasks only', () => {
    component.setFilter('active');

    expect(component.filteredTasks()).toHaveLength(2);
    expect(component.filteredTasks().every(t => !t.completed)).toBe(true);
  });

  it('should filter to completed tasks only', () => {
    component.setFilter('completed');

    expect(component.filteredTasks()).toHaveLength(1);
    expect(component.filteredTasks().every(t => t.completed)).toBe(true);
  });

  it('should update filter button active state in DOM', () => {
    component.setFilter('active');
    fixture.detectChanges();

    const activeButton = compiled.querySelector('[data-testid="filter-active"]');
    expect(activeButton?.classList.contains('active')).toBe(true);
  });
});

Testing Angular's Control Flow

Angular's @if and @empty syntax requires testing by checking element existence.

Testing @if Blocks

describe('Conditional Rendering', () => {
  it('should hide footer when no tasks exist', () => {
    const footer = compiled.querySelector('[data-testid="task-footer"]');
    expect(footer).toBeNull();
  });

  it('should show footer when tasks exist', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    fixture.detectChanges();

    const footer = compiled.querySelector('[data-testid="task-footer"]');
    expect(footer).toBeTruthy();
  });

  it('should show clear completed button only when completed tasks exist', () => {
    component.newTaskText.set('Active Task');
    component.addTask();
    fixture.detectChanges();

    let clearButton = compiled.querySelector('[data-testid="clear-completed"]');
    expect(clearButton).toBeNull();

    component.toggleTask(component.tasks()[0].id);
    fixture.detectChanges();

    clearButton = compiled.querySelector('[data-testid="clear-completed"]');
    expect(clearButton).toBeTruthy();
  });
});

Testing @empty Blocks

describe('Empty States', () => {
  it('should show empty state for "all" filter when no tasks', () => {
    component.setFilter('all');
    fixture.detectChanges();

    const emptyState = compiled.querySelector('[data-testid="empty-state"]');
    expect(emptyState?.textContent).toContain('No tasks yet');
  });

  it('should show empty state for "active" filter when no active tasks', () => {
    component.newTaskText.set('Completed Task');
    component.addTask();
    component.toggleTask(component.tasks()[0].id);

    component.setFilter('active');
    fixture.detectChanges();

    const emptyState = compiled.querySelector('[data-testid="empty-state"]');
    expect(emptyState?.textContent).toContain('No active tasks');
  });

  it('should show empty state for "completed" filter when no completed tasks', () => {
    component.newTaskText.set('Active Task');
    component.addTask();

    component.setFilter('completed');
    fixture.detectChanges();

    const emptyState = compiled.querySelector('[data-testid="empty-state"]');
    expect(emptyState?.textContent).toContain('No completed tasks');
  });
});

Testing Edge Cases

Real users find creative ways to break things. Test for them:

describe('Edge Cases', () => {
  it('should handle adding multiple tasks rapidly', () => {
    for (let i = 1; i <= 5; i++) {
      component.newTaskText.set(`Task ${i}`);
      component.addTask();
    }

    expect(component.tasks()).toHaveLength(5);
  });

  it('should handle toggling task multiple times', () => {
    component.newTaskText.set('Toggle test');
    component.addTask();
    const taskId = component.tasks()[0].id;

    component.toggleTask(taskId);
    component.toggleTask(taskId);
    component.toggleTask(taskId);

    expect(component.tasks()[0].completed).toBe(true);
  });

  it('should handle deleting non-existent task gracefully', () => {
    component.newTaskText.set('Task 1');
    component.addTask();

    component.deleteTask(9999); // Non-existent ID

    expect(component.tasks()).toHaveLength(1);
  });

  it('should maintain filter when adding new tasks', () => {
    component.setFilter('active');

    component.newTaskText.set('New Task');
    component.addTask();

    expect(component.filter()).toBe('active');
    expect(component.filteredTasks()).toHaveLength(1);
  });

  it('should clear all completed tasks at once', () => {
    for (let i = 1; i <= 3; i++) {
      component.newTaskText.set(`Task ${i}`);
      component.addTask();
      if (i % 2 === 0) {
        component.toggleTask(component.tasks()[i - 1].id);
      }
    }

    component.clearCompleted();

    expect(component.tasks().every(t => !t.completed)).toBe(true);
  });
});

Common Issues and Solutions

Router Dependencies Missing

Problem:

NG0201: No provider found for `ActivatedRoute`

Your component uses RouterLink or RouterOutlet, but tests don't automatically provide routing services.

Solution:

import { provideRouter } from '@angular/router';

describe('AppComponent', () => {
  let component: AppComponent;
  let fixture: ComponentFixture<AppComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [AppComponent],
      providers: [provideRouter([])]
    }).compileComponents();

    fixture = TestBed.createComponent(AppComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });
});

provideRouter([]) provides all routing services without needing actual routes. This replaces the deprecated RouterTestingModule.

DOM Not Updating in Tests

Problem:

it('should display new task', () => {
  component.newTaskText.set('New Task');
  component.addTask();

  const tasks = compiled.querySelectorAll('[data-testid^="task-item-"]');
  expect(tasks).toHaveLength(1); // Fails - length is 0
});

Solution:

Add fixture.detectChanges() after state changes:

it('should display new task', () => {
  component.newTaskText.set('New Task');
  component.addTask();
  fixture.detectChanges(); // Required

  const tasks = compiled.querySelectorAll('[data-testid^="task-item-"]');
  expect(tasks).toHaveLength(1); // Passes
});

Testing Dynamic Content

Problem: How to test "1 item" vs "2 items"?

Solution: Test the actual text:

describe('Task Count Display', () => {
  it('should display singular form for one task', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    fixture.detectChanges();

    const countDisplay = compiled.querySelector('[data-testid="task-count"]');
    expect(countDisplay?.textContent).toContain('1 item left');
  });

  it('should display plural form for multiple tasks', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    component.newTaskText.set('Task 2');
    component.addTask();
    fixture.detectChanges();

    const countDisplay = compiled.querySelector('[data-testid="task-count"]');
    expect(countDisplay?.textContent).toContain('2 items left');
  });
});

Testing Checkbox State

Problem: hasAttribute('checked') doesn't work for checkboxes.

Wrong:

const checkbox = compiled.querySelector('[data-testid="task-checkbox"]');
expect(checkbox?.hasAttribute('checked')).toBe(true); // Doesn't work

Right:

const checkbox = compiled.querySelector(
  '[data-testid="task-checkbox"]'
) as HTMLInputElement;

expect(checkbox.checked).toBe(true); // Works

Cast to HTMLInputElement to access the checked property.

Angular CLI Flags

Wrong flag:

ng g c my-component --skip-test  # Error: Unknown option

Right flag:

ng g c my-component --skip-tests  # Plural

For proper naming:

ng g c my-component --type=component

Without --type=component, you get my-component.ts instead of my-component.component.ts.

Quick Reference

Signals

// Read
expect(component.tasks()).toEqual([]);

// Write
component.newTaskText.set('Go to the store');

// Computed (auto-updates)
expect(component.activeTasksCount()).toBe(2);

DOM Testing

// Always call detectChanges after state changes
component.addTask();
fixture.detectChanges();

// Use data-testid for queries
const tasks = compiled.querySelectorAll('[data-testid^="task-item-"]');

Test Organization

// AAA Pattern
it('should add task', () => {
  // Arrange
  component.newTaskText.set('Task');

  // Act
  component.addTask();

  // Assert
  expect(component.tasks()).toHaveLength(1);
});

// beforeEach for setup
beforeEach(() => {
  component.newTaskText.set('Test');
  component.addTask();
});

Router Testing

providers: [provideRouter([])]

Control Flow

// Test @if by checking existence
expect(compiled.querySelector('[data-testid="footer"]')).toBeNull();
expect(compiled.querySelector('[data-testid="footer"]')).toBeTruthy();

// Test @empty by checking empty state
expect(emptyState?.textContent).toContain('No tasks yet');

What's Next

This covered component testing with signals. The series continues with:

Service Testing: Dependency injection and mocking
HTTP Testing: Testing API calls with HttpClient
Form Testing: Reactive and signal-based forms
Integration Testing: Multiple components together

Full code on GitHub.

Found an edge case I missed? Open a discussion.

Olayinka Akeju
github.com/olayeancarh
angular-vitest-testing-guide

Testing Angular 21 Components with Vitest: A Complete Guide

Olayinka Akeju — Mon, 01 Dec 2025 12:08:07 +0000

What You'll Learn

Setting up Vitest in Angular 21
Testing standalone components with signals and computed signals
Working with Angular's control flow syntax (@for, @if, @empty)
Understanding fixture.detectChanges() for DOM updates
Testing user interactions and edge cases

We're testing a full-featured task manager: add tasks, mark them complete, filter by status, and delete them. All code is on GitHub.

Project Setup

Angular 21 includes Vitest out of the box. Create a new project and you're ready to go:

ng new angular-vitest-testing-guide
cd angular-vitest-testing-guide

Verify Vitest is Installed

Check package.json:

{
  "devDependencies": {
    "@angular/build": "^21.0.0",
    "vitest": "^4.0.8"
  }
}

Check angular.json:

{
  "projects": {
    "your-project-name": {
      "architect": {
        "test": {
          "builder": "@angular/build:unit-test"
        }
      }
    }
  }
}

Run Tests

# Watch mode (default)
ng test

# Single run for CI
ng test --no-watch

Output should look like:

✓  angular-vitest-testing-guide  src/app/app.spec.ts (2 tests) 130ms
   ✓ App (2)
     ✓ should create the app 93ms
     ✓ should render title 35ms

 Test Files  1 passed (1)
      Tests  2 passed (2)

Optional: Code Coverage

Coverage needs an extra package:

npm install @vitest/coverage-v8 --save-dev
ng test --coverage

Coverage reports land in the coverage/ directory.

The Component We're Testing

The TaskList component handles everything you'd expect in a real task manager: adding tasks with validation, marking complete, filtering, and deleting. This mirrors production scenarios.

Features:

Add tasks (rejects empty/whitespace-only input)
Toggle completion status
Delete tasks
Filter by status (all, active, completed)
Clear all completed tasks
Show task counts
Display filter-specific empty states

Full component code on GitHub

Core implementation:

export class TaskListComponent {
  tasks = signal<Task[]>([]);
  filter = signal<TaskFilter>('all');

  // Computed signals auto-update when dependencies change
  activeTasksCount = computed(() =>
    this.tasks().filter(t => !t.completed).length
  );

  filteredTasks = computed(() => {
    switch (this.filter()) {
      case 'active': return this.tasks().filter(t => !t.completed);
      case 'completed': return this.tasks().filter(t => t.completed);
      default: return this.tasks();
    }
  });

  addTask() {
    const text = this.newTaskText().trim();
    if (!text) return;

    this.tasks.update(tasks => [...tasks, {
      id: Date.now(),
      text,
      completed: false,
      createdAt: new Date()
    }]);
    this.newTaskText.set('');
  }
}

Writing Your First Tests

Generate the component with its test file:

ng g c features/week-01-basics/task-list/components/task-list --type=component

Test File Structure

Basic Vitest setup for Angular components:

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { TaskListComponent } from './task-list.component';

describe('TaskListComponent', () => {
  let component: TaskListComponent;
  let fixture: ComponentFixture<TaskListComponent>;
  let compiled: HTMLElement;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [TaskListComponent] // Standalone = imports, not declarations
    }).compileComponents();

    fixture = TestBed.createComponent(TaskListComponent);
    component = fixture.componentInstance;
    compiled = fixture.nativeElement as HTMLElement;
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });
});

Key pieces:

ComponentFixture - Wrapper with testing utilities
component - Direct access to the TypeScript class
compiled - The actual rendered HTML
fixture.detectChanges() - Triggers change detection (more on this soon)

Testing Component Initialization

Verify the component starts in the correct state:

describe('Component Setup', () => {
  it('should create the component', () => {
    expect(component).toBeTruthy();
  });

  it('should initialize with empty tasks array', () => {
    expect(component.tasks()).toEqual([]);
  });

  it('should initialize with empty input text', () => {
    expect(component.newTaskText()).toBe('');
  });

  it('should initialize with "all" filter', () => {
    expect(component.filter()).toBe('all');
  });

  it('should display empty state message initially', () => {
    const emptyState = compiled.querySelector('[data-testid="empty-state"]');
    expect(emptyState).toBeTruthy();
    expect(emptyState?.textContent).toContain('No tasks yet');
  });
});

Testing Signals

Signals are functions, you call them to read, use .set() or .update() to write:

// Read a signal value
expect(component.tasks()).toEqual([]);

// Signals are just functions with ()
const currentTasks = component.tasks();
const currentFilter = component.filter();

Much simpler than Observables with their subscriptions and async complexity.

Testing User Interactions

Test the main feature: adding tasks.

describe('Adding Tasks', () => {
  it('should add a task with valid text', () => {
    // ARRANGE - Set up test data
    component.newTaskText.set('Go to the store');

    // ACT - Perform the action
    component.addTask();

    // ASSERT - Verify the result
    expect(component.tasks()).toHaveLength(1);
    expect(component.tasks()[0].text).toBe('Go to the store');
    expect(component.tasks()[0].completed).toBe(false);
  });

  it('should clear input after adding task', () => {
    component.newTaskText.set('Go to the store');
    component.addTask();

    expect(component.newTaskText()).toBe('');
  });

  it('should not add task with empty text', () => {
    component.newTaskText.set('');
    component.addTask();

    expect(component.tasks()).toHaveLength(0);
  });

  it('should not add task with whitespace-only text', () => {
    component.newTaskText.set('   ');
    component.addTask();

    expect(component.tasks()).toHaveLength(0);
  });

  it('should trim whitespace from task text', () => {
    component.newTaskText.set('  Go to the store  ');
    component.addTask();

    expect(component.tasks()[0].text).toBe('Go to the store');
  });
});

The AAA Pattern (Arrange, Act, Assert) makes tests self-documenting:

Arrange: Set up conditions
Act: Execute the action
Assert: Verify the outcome

Understanding fixture.detectChanges()

What Happens Without It

it('should display task in DOM after adding', () => {
  component.newTaskText.set('Go to the store');
  component.addTask();

  const taskItems = compiled.querySelectorAll('[data-testid^="task-item-"]');
  expect(taskItems).toHaveLength(1); // FAILS!
});

The component state updated (component.tasks() shows the task), but the DOM stayed empty. Why? Angular's change detection hasn't run yet.

The Fix

it('should display task in DOM after adding', () => {
  component.newTaskText.set('Go to the store');
  component.addTask();

  fixture.detectChanges(); // Trigger change detection

  const taskItems = compiled.querySelectorAll('[data-testid^="task-item-"]');
  expect(taskItems).toHaveLength(1); // Passes
  expect(taskItems[0].textContent).toContain('Go to the store');
});

The Rule

Call fixture.detectChanges() after state changes when testing DOM updates.

In real apps, Angular runs change detection automatically. In tests, you trigger it manually.

When to Use It

// YES - After state changes before checking DOM
component.addTask();
fixture.detectChanges();
const tasks = compiled.querySelectorAll('[data-testid^="task-item-"]');

// YES - After signal updates
component.filter.set('active');
fixture.detectChanges();

// YES - Already in beforeEach for initial render
beforeEach(async () => {
  fixture.detectChanges(); // Initial render
});

// NO - When testing component properties only
expect(component.tasks()).toHaveLength(1); // No DOM involved

Using data-testid for Reliable Tests

Notice our test queries use data-testid:

const taskItems = compiled.querySelectorAll('[data-testid^="task-item-"]');
const addButton = compiled.querySelector('[data-testid="add-button"]');

Why?

Unstable approach:

// Breaks when CSS changes
const button = compiled.querySelector('.btn-primary.add-task');

// Breaks when HTML structure changes
const task = compiled.querySelector('ul li:first-child');

Stable approach:

// Only changes when you intentionally update the test ID
const button = compiled.querySelector('[data-testid="add-button"]');

In Your Template

<!-- Static elements -->
<input data-testid="task-input" />
<button data-testid="add-button">Add</button>

<!-- Dynamic elements -->
<li [attr.data-testid]="'task-item-' + task.id">
  <input
    type="checkbox"
    [attr.data-testid]="'task-checkbox-' + task.id"
  />
</li>

This decouples tests from styling and structure, making them resilient to UI changes.

Testing Computed Signals

Computed signals auto-recalculate when dependencies change. Test this behavior:

describe('Computed Signals', () => {
  it('should calculate active tasks count correctly', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    component.newTaskText.set('Task 2');
    component.addTask();

    expect(component.activeTasksCount()).toBe(2);
    expect(component.completedTasksCount()).toBe(0);
  });

  it('should recalculate counts when task is toggled', () => {
    component.newTaskText.set('Task 1');
    component.addTask();

    expect(component.activeTasksCount()).toBe(1);
    expect(component.completedTasksCount()).toBe(0);

    // Toggle to completed
    const taskId = component.tasks()[0].id;
    component.toggleTask(taskId);

    expect(component.activeTasksCount()).toBe(0);
    expect(component.completedTasksCount()).toBe(1);
  });

  it('should update filtered tasks when filter changes', () => {
    component.newTaskText.set('Active Task');
    component.addTask();
    component.newTaskText.set('Completed Task');
    component.addTask();
    component.toggleTask(component.tasks()[1].id);

    component.setFilter('all');
    expect(component.filteredTasks()).toHaveLength(2);

    component.setFilter('active');
    expect(component.filteredTasks()).toHaveLength(1);
    expect(component.filteredTasks()[0].completed).toBe(false);

    component.setFilter('completed');
    expect(component.filteredTasks()).toHaveLength(1);
    expect(component.filteredTasks()[0].completed).toBe(true);
  });
});

Computed signals just work, no manual triggers needed:

const activeCount = component.activeTasksCount(); // Always current
const filtered = component.filteredTasks(); // Auto-filtered

Testing Task Toggling

describe('Toggling Tasks', () => {
  beforeEach(() => {
    component.newTaskText.set('Test task');
    component.addTask();
  });

  it('should mark task as completed', () => {
    const taskId = component.tasks()[0].id;
    component.toggleTask(taskId);

    expect(component.tasks()[0].completed).toBe(true);
  });

  it('should unmark completed task', () => {
    const taskId = component.tasks()[0].id;

    component.toggleTask(taskId); // Complete
    component.toggleTask(taskId); // Uncomplete

    expect(component.tasks()[0].completed).toBe(false);
  });

  it('should toggle correct task when multiple exist', () => {
    component.newTaskText.set('Second task');
    component.addTask();

    const secondTaskId = component.tasks()[1].id;
    component.toggleTask(secondTaskId);

    expect(component.tasks()[0].completed).toBe(false);
    expect(component.tasks()[1].completed).toBe(true);
  });

  it('should update DOM when task is toggled', () => {
    const taskId = component.tasks()[0].id;

    component.toggleTask(taskId);
    fixture.detectChanges();

    const checkbox = compiled.querySelector(
      `[data-testid="task-checkbox-${taskId}"]`
    ) as HTMLInputElement;

    expect(checkbox.checked).toBe(true);
  });
});

Note: The beforeEach inside this describe block runs before each test in this block, reducing repetition.

Testing Task Deletion

describe('Deleting Tasks', () => {
  it('should delete a task', () => {
    component.newTaskText.set('Task to delete');
    component.addTask();

    const taskId = component.tasks()[0].id;
    component.deleteTask(taskId);

    expect(component.tasks()).toHaveLength(0);
  });

  it('should delete correct task from list', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    component.newTaskText.set('Task 2');
    component.addTask();
    component.newTaskText.set('Task 3');
    component.addTask();

    const middleTaskId = component.tasks()[1].id;
    component.deleteTask(middleTaskId);

    expect(component.tasks()).toHaveLength(2);
    expect(component.tasks()[0].text).toBe('Task 1');
    expect(component.tasks()[1].text).toBe('Task 3');
  });

  it('should remove task from DOM', () => {
    component.newTaskText.set('Task to delete');
    component.addTask();
    fixture.detectChanges();

    const taskId = component.tasks()[0].id;
    component.deleteTask(taskId);
    fixture.detectChanges();

    const taskElement = compiled.querySelector(`[data-testid="task-item-${taskId}"]`);
    expect(taskElement).toBeNull();
  });
});

Testing Filters

describe('Filtering Tasks', () => {
  beforeEach(() => {
    component.newTaskText.set('Active 1');
    component.addTask();
    component.newTaskText.set('Completed 1');
    component.addTask();
    component.newTaskText.set('Active 2');
    component.addTask();

    component.toggleTask(component.tasks()[1].id);
  });

  it('should show all tasks by default', () => {
    expect(component.filter()).toBe('all');
    expect(component.filteredTasks()).toHaveLength(3);
  });

  it('should filter to active tasks only', () => {
    component.setFilter('active');

    expect(component.filteredTasks()).toHaveLength(2);
    expect(component.filteredTasks().every(t => !t.completed)).toBe(true);
  });

  it('should filter to completed tasks only', () => {
    component.setFilter('completed');

    expect(component.filteredTasks()).toHaveLength(1);
    expect(component.filteredTasks().every(t => t.completed)).toBe(true);
  });

  it('should update filter button active state in DOM', () => {
    component.setFilter('active');
    fixture.detectChanges();

    const activeButton = compiled.querySelector('[data-testid="filter-active"]');
    expect(activeButton?.classList.contains('active')).toBe(true);
  });
});

Testing Angular's Control Flow

Angular's @if and @empty syntax requires testing by checking element existence.

Testing @if Blocks

describe('Conditional Rendering', () => {
  it('should hide footer when no tasks exist', () => {
    const footer = compiled.querySelector('[data-testid="task-footer"]');
    expect(footer).toBeNull();
  });

  it('should show footer when tasks exist', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    fixture.detectChanges();

    const footer = compiled.querySelector('[data-testid="task-footer"]');
    expect(footer).toBeTruthy();
  });

  it('should show clear completed button only when completed tasks exist', () => {
    component.newTaskText.set('Active Task');
    component.addTask();
    fixture.detectChanges();

    let clearButton = compiled.querySelector('[data-testid="clear-completed"]');
    expect(clearButton).toBeNull();

    component.toggleTask(component.tasks()[0].id);
    fixture.detectChanges();

    clearButton = compiled.querySelector('[data-testid="clear-completed"]');
    expect(clearButton).toBeTruthy();
  });
});

Testing @empty Blocks

describe('Empty States', () => {
  it('should show empty state for "all" filter when no tasks', () => {
    component.setFilter('all');
    fixture.detectChanges();

    const emptyState = compiled.querySelector('[data-testid="empty-state"]');
    expect(emptyState?.textContent).toContain('No tasks yet');
  });

  it('should show empty state for "active" filter when no active tasks', () => {
    component.newTaskText.set('Completed Task');
    component.addTask();
    component.toggleTask(component.tasks()[0].id);

    component.setFilter('active');
    fixture.detectChanges();

    const emptyState = compiled.querySelector('[data-testid="empty-state"]');
    expect(emptyState?.textContent).toContain('No active tasks');
  });

  it('should show empty state for "completed" filter when no completed tasks', () => {
    component.newTaskText.set('Active Task');
    component.addTask();

    component.setFilter('completed');
    fixture.detectChanges();

    const emptyState = compiled.querySelector('[data-testid="empty-state"]');
    expect(emptyState?.textContent).toContain('No completed tasks');
  });
});

Testing Edge Cases

Real users find creative ways to break things. Test for them:

describe('Edge Cases', () => {
  it('should handle adding multiple tasks rapidly', () => {
    for (let i = 1; i <= 5; i++) {
      component.newTaskText.set(`Task ${i}`);
      component.addTask();
    }

    expect(component.tasks()).toHaveLength(5);
  });

  it('should handle toggling task multiple times', () => {
    component.newTaskText.set('Toggle test');
    component.addTask();
    const taskId = component.tasks()[0].id;

    component.toggleTask(taskId);
    component.toggleTask(taskId);
    component.toggleTask(taskId);

    expect(component.tasks()[0].completed).toBe(true);
  });

  it('should handle deleting non-existent task gracefully', () => {
    component.newTaskText.set('Task 1');
    component.addTask();

    component.deleteTask(9999); // Non-existent ID

    expect(component.tasks()).toHaveLength(1);
  });

  it('should maintain filter when adding new tasks', () => {
    component.setFilter('active');

    component.newTaskText.set('New Task');
    component.addTask();

    expect(component.filter()).toBe('active');
    expect(component.filteredTasks()).toHaveLength(1);
  });

  it('should clear all completed tasks at once', () => {
    for (let i = 1; i <= 3; i++) {
      component.newTaskText.set(`Task ${i}`);
      component.addTask();
      if (i % 2 === 0) {
        component.toggleTask(component.tasks()[i - 1].id);
      }
    }

    component.clearCompleted();

    expect(component.tasks().every(t => !t.completed)).toBe(true);
  });
});

Common Issues and Solutions

Router Dependencies Missing

Problem:

NG0201: No provider found for `ActivatedRoute`

Your component uses RouterLink or RouterOutlet, but tests don't automatically provide routing services.

Solution:

import { provideRouter } from '@angular/router';

describe('AppComponent', () => {
  let component: AppComponent;
  let fixture: ComponentFixture<AppComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [AppComponent],
      providers: [provideRouter([])]
    }).compileComponents();

    fixture = TestBed.createComponent(AppComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });
});

provideRouter([]) provides all routing services without needing actual routes. This replaces the deprecated RouterTestingModule.

DOM Not Updating in Tests

Problem:

it('should display new task', () => {
  component.newTaskText.set('New Task');
  component.addTask();

  const tasks = compiled.querySelectorAll('[data-testid^="task-item-"]');
  expect(tasks).toHaveLength(1); // Fails - length is 0
});

Solution:

Add fixture.detectChanges() after state changes:

it('should display new task', () => {
  component.newTaskText.set('New Task');
  component.addTask();
  fixture.detectChanges(); // Required

  const tasks = compiled.querySelectorAll('[data-testid^="task-item-"]');
  expect(tasks).toHaveLength(1); // Passes
});

Testing Dynamic Content

Problem: How to test "1 item" vs "2 items"?

Solution: Test the actual text:

describe('Task Count Display', () => {
  it('should display singular form for one task', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    fixture.detectChanges();

    const countDisplay = compiled.querySelector('[data-testid="task-count"]');
    expect(countDisplay?.textContent).toContain('1 item left');
  });

  it('should display plural form for multiple tasks', () => {
    component.newTaskText.set('Task 1');
    component.addTask();
    component.newTaskText.set('Task 2');
    component.addTask();
    fixture.detectChanges();

    const countDisplay = compiled.querySelector('[data-testid="task-count"]');
    expect(countDisplay?.textContent).toContain('2 items left');
  });
});

Testing Checkbox State

Problem: hasAttribute('checked') doesn't work for checkboxes.

Wrong:

const checkbox = compiled.querySelector('[data-testid="task-checkbox"]');
expect(checkbox?.hasAttribute('checked')).toBe(true); // Doesn't work

Right:

const checkbox = compiled.querySelector(
  '[data-testid="task-checkbox"]'
) as HTMLInputElement;

expect(checkbox.checked).toBe(true); // Works

Cast to HTMLInputElement to access the checked property.

Angular CLI Flags

Wrong flag:

ng g c my-component --skip-test  # Error: Unknown option

Right flag:

ng g c my-component --skip-tests  # Plural

For proper naming:

ng g c my-component --type=component

Without --type=component, you get my-component.ts instead of my-component.component.ts.

Quick Reference

Signals

// Read
expect(component.tasks()).toEqual([]);

// Write
component.newTaskText.set('Go to the store');

// Computed (auto-updates)
expect(component.activeTasksCount()).toBe(2);

DOM Testing

// Always call detectChanges after state changes
component.addTask();
fixture.detectChanges();

// Use data-testid for queries
const tasks = compiled.querySelectorAll('[data-testid^="task-item-"]');

Test Organization

// AAA Pattern
it('should add task', () => {
  // Arrange
  component.newTaskText.set('Task');

  // Act
  component.addTask();

  // Assert
  expect(component.tasks()).toHaveLength(1);
});

// beforeEach for setup
beforeEach(() => {
  component.newTaskText.set('Test');
  component.addTask();
});

Router Testing

providers: [provideRouter([])]

Control Flow

// Test @if by checking existence
expect(compiled.querySelector('[data-testid="footer"]')).toBeNull();
expect(compiled.querySelector('[data-testid="footer"]')).toBeTruthy();

// Test @empty by checking empty state
expect(emptyState?.textContent).toContain('No tasks yet');

What's Next

This covered component testing with signals. The series continues with:

Service Testing: Dependency injection and mocking
HTTP Testing: Testing API calls with HttpClient
Form Testing: Reactive and signal-based forms
Integration Testing: Multiple components together

Full code on GitHub.

Found an edge case I missed? Open a discussion.

Olayinka Akeju
github.com/olayeancarh
angular-vitest-testing-guide

Unlocking Angular's Data Binding: A Deep Dive into Interpolation, Property, Event, and Two-Way Binding

Olayinka Akeju — Sun, 31 Aug 2025 09:29:38 +0000

For those of us who have been in the trenches with Angular, we know that at the heart of its power lies a robust data binding system. It is the mechanism that seamlessly synchronizes our component's logic with its view, creating the dynamic and interactive user experiences we strive to build.

In this deep dive, we'll move beyond the basics to explore the nuances of Angular's four primary data binding types. We'll examine their syntax, understand how they work under the hood, and discuss practical use cases and potential pitfalls. As seasoned developers know, mastering these concepts is crucial for writing clean, efficient, and maintainable Angular applications.

The Foundation: What Is Data Binding?

At its core, data binding is the communication between your component's TypeScript code and its HTML template. It's the automated synchronization of data that ensures any change in the component's state is immediately reflected in the user interface, and vice versa. This bi-directional conversation is what makes Angular applications feel so alive and responsive.

Think of it as a set of communication channels. Some channels are one-way, broadcasting information from the component to the template, while others are two-way, allowing for a continuous dialogue. With the evolution of Angular, particularly from version 16 onwards, advancements in change detection and the introduction of signals have further refined this process, offering us more granular control and improved performance.

1. Interpolation: The Expressive Display `{{ }}`

Interpolation is often the first type of data binding that Angular developers encounter. It's a straightforward, one-way binding technique that allows you to embed expressions directly into your HTML template.

Syntax and How It Works

You use double curly braces {{ expression }} to denote an interpolation expression. Angular evaluates the expression within the braces and converts the result to a string before displaying it in the view.

<!-- user.component.html -->
<h2>Welcome back, {{ username }}!</h2>
<p>Your current score is: {{ getScore() }}</p>

// user.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-user',
  standalone: true,
  templateUrl: './user.component.html',
})
export class UserComponent {
  username = 'JaneDoe';

  getScore(): number {
    return 100;
  }
}

In this example, Angular will replace {{ username }} with the value of the username property and {{ getScore() }} with the return value of the getScore method.

<!-- Rendered Output -->
<h2>Welcome back, JaneDoe!</h2>
<p>Your current score is: 100</p>

Use Cases and Practical Tips

Interpolation is ideal for rendering simple data values like strings and numbers. However, it's crucial to keep the expressions within the curly braces simple. Complex logic or functions that trigger extensive computations can negatively impact performance, as they are executed on every change detection cycle.

Key Takeaway: Use interpolation for displaying read-only data from your component. For more complex scenarios, consider using property binding, which we will be seeing next.

2. Property Binding: The DOM Manipulator `[]`

Property binding is another form of one-way binding that allows us to set the properties of HTML elements and directives. Unlike interpolation, which primarily deals with string values, property binding can handle any data type, including booleans, arrays, and objects.

Syntax and How It Works

Property binding uses square brackets [] around the target property. The expression on the right-hand side of the equal is evaluated, and the result is assigned to the property.

[property]="expression"

<!-- image-loader.component.html -->
<img [src]="imageUrl" [alt]="imageAltText">
<button [disabled]="isButtonDisabled">Click me</button>
<div [class.active]="isSelected">Content</div>

// image-loader.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-image-loader',
  standalone: true,
  templateUrl: './image-loader.component.html',
})
export class ImageLoaderComponent {
  imageUrl = 'path/to/image.jpg';
  imageAltText = 'A descriptive text for the image';
  isButtonDisabled = true;
  isSelected = false;
}

Here, the alt and src attributes of the img element, the disabled property of the button, and class.active are bound to the corresponding component properties.

Use Cases and Practical Tips

Property binding is incredibly versatile. You can use it to:

Set element properties dynamically (e.g., [disabled]="isLoading").
Pass data from a parent component to a child component (e.g., [data]="parentData").
Bind to class and style properties of dynamic styling (e.g., [style.backgroundColor]="themeColor").

A common point of confusion is when to use interpolation versus property binding for string values. While both can work, a good rule of thumb is to use property binding when the value is of a non-string type, or when you want to make it clear that you are binding to a DOM property.

Key Takeaway: Property binding is your go-to for setting element properties and passing data to child components, especially for non-string values.

3. Event Binding: The Listener `()`

Event binding allows your application to respond to user interactions, such as clicks, mouse movements, and keyboard input. It facilitates a one-way communication channel from the templates to the component, enabling you to trigger methods in your component in response to DOM events.

Syntax and How it Works

Event binding uses parentheses () around the event name. When the event is triggered, the expression on the right-hand side of the equals sign is executed.

<!-- counter.component.html -->
<p>Count: {{ count }}</p>
<button (click)="increment()">Increment</button>

// counter.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-counter',
  standalone: true,
  templateUrl: './counter.component.html',
})
export class CounterComponent {
  count = 0;

  increment() {
    this.count++;
  }
}

In this example, clicking the button triggers the increment method in the component, which updates the count property.
You can also pass the event object itself using the $event keyword, giving you access to valuable event data.

<input (input)="onInputChange($event)">

Use cases and Practical Tips

Event binding is fundamental for creating interactive applications. It's the primary way to capture user input and trigger application logic. When dealing with complex event handling. It's a good practice to keep the template expression minimal and delegate the heavy lifting to a component method.

Key Takeaway: Use event binding to listen for and respond to user actions, keeping the template logic concise.

4. Two-Way Binding: The Synchronizer `[()]`

Two-way data binding provides a seamless, bi-directional synchronization between the component and the template. Any change in the view updates the component's state, and any change in the component's state is immediately reflected in the view.

Syntax and How It Works

Two-way binding combines property and event binding into a single syntax, often referred to as the "banana-in-a-box" [()].

[(property)]="expression"

The most common use case for two-way binding is with forms. Using the ngModel directive, which requires importing FormsModule.

<!-- user-form.component.html -->
<input [(ngModel)]="username" name="username">
<p>Hello, {{ username }}!</p>

// user-form.component.ts
import { Component } from '@angular/core';
import { FormsModule } from '@angular/forms';

@Component({
  selector: 'app-user-form',
  standalone: true,
  imports: [FormsModule],
  templateUrl: './user-form.component.html',
})
export class UserFormComponent {
  username = 'JohnDoe';
}

The Rise of Signals in Two-Way Binding

With Angular 17 and beyond, signals offer a modern and often more performant way to achieve two-way binding, especially in parent-child component communication. The model() function creates a writable signal that can be bound from a parent component.

Parent Component:

// app.component.ts
import { Component, signal } from '@angular/core';
import { ChildComponent } from './child.component';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [ChildComponent],
  template: `
    <app-child [(message)]="parentMessage"></app-child>
    <p>Parent sees: {{ parentMessage() }}</p>
  `,
})
export class AppComponent {
  parentMessage = signal('Hello from parent');
}

Child Component:

// child.component.ts
import { Component, model } from '@angular/core';

@Component({
  selector: 'app-child',
  standalone: true,
  template: `
    <input [value]="message()" (input)="onInput($event)">
  `,
})
export class ChildComponent {
  message = model.required<string>();

  onInput(event: Event) {
    this.message.set((event.target as HTMLInputElement).value);
  }
}

Use Cases and Practical Tips

While two-way binding is convenient for forms, it's important to use it judiciously. Overusing it can sometimes make the data flow in your application harder to trace and debug. For complex interactions, it's often better to use a combination of property binding and event binding to have more explicit control.

Key Takeaway: Two-way binding is excellent for form inputs, but consider the explicitness of property binding for more complex component interactions. Explore signals for a more modern approach to two-way binding.

Integrating Data Binding: Parent-Child Communication

The different types of data binding often work together, particularly in the context of parent-child component communication.

Parent to Child: Use property binding to pass data down to a child component.
Child to Parent: Use event binding to emit events from the child to the parent.

The pattern promotes component encapsulation and reusability, which are cornerstones of good Angular architecture.

Best Practices for Optimal Performance

To ensure your use of data binding is efficient, keep these best practices in mind:

Avoid Complex Template Expressions: Keep your template logic simple. For complex transformations, use pipes.
Leverage OnPush Change Detection: For components that only depend on their inputs, using the OnPush change detection strategy can significantly improve performance.
Use trackBy with *ngFor: When rendering lists, provide a trackBy function to help Angular identify which items have changed, added, or been removed, preventing unnecessary DOM manipulation.

Conclusion

Mastering data binding in Angular is a journey from understanding the basics to appreciating the subtleties of each type. By choosing the right tool for the job, be it the simplicity of interpolation, the power of property binding, the responsiveness of event binding, or the convenience of two-way binding, you can build applications that are not only functional but also performant and maintainable.

As Angular continues to evolve with features like signals, our approach to data binding will also adapt. I encourage you to experiment with these concepts in your own projects. Try refactoring a component to use signals for two-way binding or optimizing a list with trackBy. The practical application of these techniques is where true mastery is forged.

Simple Guide to Dockerizing an Angular App

Olayinka Akeju — Wed, 08 May 2024 00:28:02 +0000

Introduction

Being able to containerize an application helps simplify the software development process and also facilitates collaboration across teams and devices. Recently, I had the chance to dockerize an Angular application, and I'm thrilled to share the step-by-step guide I used to do this.

In this guide, we will explore dockerizing an Angular application for both development and production environments.

Prerequisites

Before you proceed, ensure the following are installed and configured on your PC.

Docker
Node
Angular CLI

Create a simple Angular application

Generate your angular application

$ ng new angular-docker

Enter Into the application folder

$ cd angular-docker

At this point, we should have an angular application with the below structure

Create a Dockerfile for the Development Environment.

At the root of our application folder, we will create a Dockerfile for development and name it Dockerfile.dev. Here is how our Dockerfile.dev will appear:

# Specify a node base imageFROM node:alpine# Work directoryWORKDIR /app# Install some dependenciesCOPY package.json .RUN npm install -g @angular/cliRUN npm installCOPY . .# Default CommandCMD ["ng", "serve", "--host", "0.0.0.0"]

Add a .dockerignore file to the root of the application. This will help to exclude unnecessary files in our Docker image. Here's what our .dockerignore file will look like

# Exclude node_modules (already included in the Dockerfile)node_modules/# Exclude build artifactsdist/# Exclude development-specific files.git/.gitignore.editorconfig.vscode/

Create Docker Image

$ docker build -t app:angular-docker -f Dockerfile.dev .

-t: [image_name]:[image_tag]
-f: development docker file
.: current directory

Once we hit the enter key, our build will start and we will have the below when it finishes. This will output the build steps, and image id as shown below.

Run docker container

$ docker run -p 4200:4200 --name demo --rm app:angular-docker

-p: [host_port]:[container_port]
--name: container name
--rm: deletes container once it is stopped

We can verify the running container in a different terminal by running

$ docker ps

This will show us the running container as shown below

At this point we can navigate to our running application by opening our browser and visiting http://localhost:4200/ and we will see our dockerized angular application.

Create a Dockerfile for Production Environment.

At the root of our application folder, we will create a Dockerfile for production and name it as Dockerfile.

We will use Nginx to serve our static files.

Here is how our Dockerfile will look:

# Stage 1: Build application# Specify a base imageFROM node:20-alpine as builder# Work directoryWORKDIR /app# Install some dependenciesCOPY package.json .RUN npm installCOPY . .# Build RUN npm run build --prod# Stage 2: Deploy stageFROM nginxCOPY --from=builder /app/dist/angular-docker/browser /usr/share/nginx/html

We can go ahead to build our image and create a container.

$ docker build -t app:angular-docker .$ docker run --rm -p 8080:80 angular-docker

We can navigate to the application at http://localhost:8080

Final Application Structure

Conclusion

I hope this guide has been helpful in dockerizing your Angular application. I have explained everything in simple terms, hoping that you understood it all.

If you have trouble understanding or find the guide unsatisfactory, please feel free to contact me. Until then, see you in the next guide.