Forem: Dimitris Kiriakakis

Event-Driven State Management with NgRx Signal Store

Dimitris Kiriakakis — Mon, 03 Nov 2025 16:02:36 +0000

In my previous article, we explored how NgRx Signal Store simplifies state management in Angular by removing traditional boilerplate. We built a task tracker that used withMethods() to handle all state changes and async operations.

While that approach works well for small features, it has a hidden cost: tight coupling between what happens and how it happens. When a component calls store.createTask(), it assumes the store will handle validation, API calls, state updates, and error handling in a specific way. As the app grows, this coupling makes maintenance and cross team collaboration.. difficult.

And this is where the Events Plugin for NgRx Signal Store comes into play, a modern take on Flux architecture that decouples events from their handlers, making state flows more predictable and scalable. In this post, we'll develop an event-based Signal Store using the NgRx Events Plugin. You'll find the complete implementation in the repository linked at the end.

The Problem with Direct Method Calls

Let's look at a method from our original task store:

async createTask(task: Omit<Task, 'id' | 'createdAt'>) {
  patchState(store, { isLoading: true });

  try {
    const newTask = await firstValueFrom(service.createTask(task));
    const currentTasks = store.taskEntities();
    updateTasks([...currentTasks, newTask]);
    patchState(store, { isLoading: false });
    return newTask;
  } catch (error) {
    patchState(store, { isLoading: false });
    throw error;
  }
}

What's happening here?

The method handles loading state
Makes an API call
Updates task entities
Manages error handling

All in one place. This seems convenient, but consider these scenarios:

What if multiple actions need to trigger the same side effect?
What if creating a task should also trigger analytics?
What if we want to replay events for debugging?

💡 With direct method calls, we'd need to modify the method itself or duplicate logic. Events solve this by decoupling the "what" from the "how".

Why Event-Driven Architecture?

Events introduce a layer of indirection that transforms our tightly coupled method into a loosely coupled system. Instead of create this task, we emit task creation was requested. This shift enables multiple parts of our application to react independently to the same event.

But events alone aren't enough. We need a pattern that defines how they flow through our application. That's where Flux comes in.

Understanding Flux Architecture

Flux is an application architecture pattern that enforces unidirectional data flow. Unlike traditional MVC patterns where data can flow in multiple directions, Flux makes application behavior predictable and easier to trace.

The core principle: Actions trigger changes → Updates happen to state → Views reflect new state → Views can trigger new actions. This creates a circular but unidirectional flow.

As the diagram shows, events flow in cycles through our application:

Event: User interactions or system events trigger the flow
Dispatcher: Routes events to the appropriate handlers
Store: Reducers update state, effects handle side effects like API calls
View: Components react to state changes
Back to Event: View interactions create new events, completing the cycle

💡 This separation means that components don’t need to know about API details, effects can be modified without touching the components, multiple effects can react to the same event, and all state changes remain fully traceable through events.

How the Events Plugin Implements Flux

The Events Plugin brings Flux to NgRx Signal Store with modern TypeScript and Signals. Events replace traditional actions through type-safe event creators with eventGroup(), while reducers handle state updates via pure functions using withReducer() and on(). Side effects are managed through observable-based effects with withEffects(), and Signals replace manual subscriptions by providing automatic change detection. Throughout the entire flow, TypeScript inference ensures full type safety from event creation to state updates.

Setting Up the Events Plugin

Now that we understand the architecture, let's implement it. The Events Plugin ships with NgRx Signals since version 19.2 (also available in latest v20.0.1):

npm add @ngrx/signals@latest

With the plugin installed, we can define the events that will flow through our task tracker application.

Defining Task Events

The first step in event-driven architecture is defining all the events that can occur in our system. Think of events as a complete chronicle of everything that happens in our application: both user actions and system responses.

We use eventGroup() to organize related events under a common source, which helps us understand where events originate and makes debugging easier. For our task tracker, we'll create two event groups:

// src/app/stores/task-store/task.events.ts
import { type } from '@ngrx/signals';
import { eventGroup } from '@ngrx/signals/events';
import { Task, TaskStatus } from '../../interfaces/task';

export const taskPageEvents = eventGroup({
  source: 'Task Page',
  events: {
    opened: type<void>(),
    taskCreated: type<Omit<Task, 'id' | 'createdAt'>>(),
    taskDeleted: type<string>(),
    taskStatusChanged: type<{
      id: string;
      status: TaskStatus;
      previousStatus: TaskStatus;
    }>(),
    pageChanged: type<number>(),
  },
});

export const taskApiEvents = eventGroup({
  source: 'Task API',
  events: {
    tasksLoadedSuccess: type<Task[]>(),
    tasksLoadedFailure: type<string>(),
    taskCreatedSuccess: type<Task>(),
    taskCreatedFailure: type<string>(),
    taskDeletedSuccess: type<string>(),
    taskDeletedFailure: type<string>(),
    taskStatusChangedSuccess: type<{ id: string; status: TaskStatus }>(),
    taskStatusChangedFailure: type<{
      id: string;
      previousStatus: TaskStatus;
      error: string;
    }>(),
  },
});

Understanding the Event Structure

The separation into two groups is intentional and follows the Flux pattern:

Page Events (taskPageEvents) represent user intentions — the "what the user wants to do":

opened - User navigated to the task board
taskCreated - User submitted a new task (we don't have the ID yet)
taskDeleted - User clicked delete on a task
taskStatusChanged - User moved a task to a different column

These events describe what happened from the user's perspective, without any knowledge of how the system will handle them.

API Events (taskApiEvents) represent system outcomes — the "what actually happened":

tasksLoadedSuccess / tasksLoadedFailure - The result of fetching tasks
taskCreatedSuccess / taskCreatedFailure - The result of creating a task
Each operation has both success and failure events to handle all possible outcomes

This separation creates a clear request-response pattern: page events trigger effects, which call APIs, which emit API events, which trigger reducers. The data flow becomes a traceable sequence of events rather than hidden method calls.

Notice also that failure events include enough context to handle errors properly — for example, taskStatusChangedFailure includes the previousStatus so we can roll back optimistic updates.

Implementing Reducers

Reducers in NGRX Signals Events are declarative configurations that define how state should update in response to events. Using the on() function, we map event types to state update instructions. They return state update instructions (like setAllEntities(), addEntity(), or partial state objects) that compose into the store.

💡 Reducers define what state changes should happen when events occur. Effects - which we will cover next - handle side effects like API calls and dispatch result events that our reducers process.

The Reducer Pattern

We use withReducer() wrapped in a signalStoreFeature() to create a composable reducer feature:

// src/app/stores/task-store/task.reducer.ts
import { on, withReducer } from '@ngrx/signals/events';
import {
  setAllEntities,
  addEntity,
  removeEntity,
  updateEntity,
} from '@ngrx/signals/entities';
import { taskPageEvents, taskApiEvents } from './task.events';
import { signalStoreFeature } from '@ngrx/signals';
import { Task, TaskStatus } from '../../interfaces/task';

export function withTaskReducer() {
  return signalStoreFeature(
    withReducer(
      // Handle loading states
      on(taskPageEvents.opened, () => {
        return { isLoading: true };
      }),

      // Handle successful task loading
      // In NGRX Signals Events, the on() handler receives only the event (not state)
      // The event object has a .payload property containing the data
      on(taskApiEvents.tasksLoadedSuccess, (event: { payload: Task[] }) => {
        return [
          setAllEntities(event.payload, { collection: 'task' }),
          { isLoading: false },
        ];
      }),

      // Handle failed task loading
      on(taskApiEvents.tasksLoadedFailure, (event: { payload: string }) => {
        return {
          isLoading: false,
          error: event.payload,
        };
      }),

      // Handle successful task creation
      on(taskApiEvents.taskCreatedSuccess, (event: { payload: Task }) => {
        return addEntity(event.payload, { collection: 'task' });
      }),

      // Handle successful task deletion
      on(taskApiEvents.taskDeletedSuccess, (event: { payload: string }) => {
        return removeEntity(event.payload, { collection: 'task' });
      }),

      // ..more reducers (see below)
}

Understanding Reducer Mechanics

Each on() handler maps an event type to state update instructions. The handler receives a single event parameter with a payload property containing the event data, and returns:

Partial state update: { isLoading: true } - which merges into current state
Array of updates: [setAllEntities(...), { isLoading: false }] - which applies multiple updates
Entity operation: addEntity(...), updateEntity(...), removeEntity(...) - which modifies an entity collection

Why explicit typing? Type annotations like (event: { payload: Task[] }) ensure type safety and improve IDE support. While the Events Plugin provides type inference, explicit annotations prevent payload access errors and enable better autocompletion during development.

The Power of Declarative Updates

One of the most powerful patterns enabled by event-driven reducers is optimistic updates with automatic rollbacks. Consider how we handle task status changes:

      // Handle optimistic status update
      on(
        taskPageEvents.taskStatusChanged,
        (event: { payload: { id: string; status: TaskStatus } }) => {
          return updateEntity(
            { id: event.payload.id, changes: { status: event.payload.status } },
            { collection: 'task' }
          );
        }
      ),

      // Handle status update failure (revert)
      on(
        taskApiEvents.taskStatusChangedFailure,
        (event: {
          payload: { id: string; previousStatus: TaskStatus; error: string };
        }) => {
          return updateEntity(
            {
              id: event.payload.id,
              changes: { status: event.payload.previousStatus },
            },
            { collection: 'task' }
          );
        }
      )

This pattern provides immediate UI feedback while maintaining data consistency. The user sees the change instantly, and if the server rejects it, the state automatically reverts—all through declarative event handlers with no manual rollback logic.

Implementing Effects

While reducers handle declarative state updates, effects manage side effects: API calls, external services, logging, and any interaction with the outside world. Effects are RxJS observables that listen for specific events, perform asynchronous operations, and dispatch result events back to the store.

The key benefit of effects is separation of concerns: reducers remain declarative and focused on state shape, while effects encapsulate all asynchronous and external operations.

The Effect Pattern

Effects use the Events service to listen for events via events.on(), perform side effects (like HTTP requests), handle success/error cases, and dispatch result events. Like reducers, effects are wrapped in signalStoreFeature() using withEffects() to create a composable effect feature:

// src/app/stores/task-store/task.effects.ts
import { inject } from '@angular/core';
import { Events, withEffects } from '@ngrx/signals/events';
import { signalStoreFeature } from '@ngrx/signals';
import { exhaustMap, tap, catchError, concatMap } from 'rxjs/operators';
import { of } from 'rxjs';
import { TaskService } from '../../services/task.service';
import { taskPageEvents, taskApiEvents } from './task.events';
import { Task } from '../../interfaces/task';

export function withTaskEffects() {
  return signalStoreFeature(
    withEffects(
      (
        // Store type is dynamically composed, using Record for flexibility
        store: Record<string, unknown>,
        events = inject(Events),
        taskService = inject(TaskService)
      ) => ({
        // Load tasks when page opens
        loadTasks$: events.on(taskPageEvents.opened).pipe(
          exhaustMap(() =>
            taskService.getTasks(1, 10).pipe(
              tap(response => {
                console.log('[Effect] Response from getTasks:', response);
              }),
              catchError((error: { message: string }) =>
                of(taskApiEvents.tasksLoadedFailure(error.message))
              ),
              concatMap((response: { tasks: Task[] } | { type: string }) => {
                if ('type' in response) {
                  // Already an event (error)
                  return of(response);
                }
                // Dispatch success with tasks array
                console.log(
                  '[Effect] Dispatching tasksLoadedSuccess with:',
                  response.tasks
                );
                return of(taskApiEvents.tasksLoadedSuccess(response.tasks));
              })
            )
          )
        ),

        // Create task
        createTask$: events.on(taskPageEvents.taskCreated).pipe(
          exhaustMap(event =>
            taskService.createTask(event.payload).pipe(
              catchError((error: { message: string }) =>
                of(taskApiEvents.taskCreatedFailure(error.message))
              ),
              concatMap((task: Task | { type: string }) =>
                'type' in task
                  ? of(task)
                  : of(taskApiEvents.taskCreatedSuccess(task))
              )
            )
          )
        ),

        // Delete task
        deleteTask$: events.on(taskPageEvents.taskDeleted).pipe(
          exhaustMap(event =>
            taskService.deleteTask(event.payload).pipe(
              catchError((error: { message: string }) =>
                of(taskApiEvents.taskDeletedFailure(error.message))
              ),
              concatMap(() =>
                of(taskApiEvents.taskDeletedSuccess(event.payload))
              )
            )
          )
        ),

        // Change task status
        changeTaskStatus$: events.on(taskPageEvents.taskStatusChanged).pipe(
          exhaustMap(event => {
            return taskService
              .updateTaskStatus(event.payload.id, event.payload.status)
              .pipe(
                concatMap(() =>
                  of(
                    taskApiEvents.taskStatusChangedSuccess({
                      id: event.payload.id,
                      status: event.payload.status,
                    })
                  )
                ),
                catchError((error: { message: string }) =>
                  of(
                    taskApiEvents.taskStatusChangedFailure({
                      id: event.payload.id,
                      previousStatus: event.payload.previousStatus,
                      error: error.message,
                    })
                  )
                )
              );
          })
        ),
      })
    )
  );
}

Understanding Effect Mechanics

Let's break down the pattern using the loadTasks$ effect as an example:

Listening for events: events.on(taskPageEvents.opened) creates an observable that emits whenever the opened event is dispatched
Making sure that we handle concurrency: exhaustMap ignores new events while the current request is in progress. This prevents duplicate API calls if the user rapidly triggers the same action
Calling an async service method: taskService.getTasks(1, 10) performs the HTTP request and returns an observable
Error handling: catchError transforms errors into failure events, ensuring the observable stream continues and errors are handled gracefully
Transforming responses: concatMap checks if we already have an event object (from catchError) or if we need to wrap the successful response in a success event
Dispatching result events: The effect returns observables that emit event objects (created by event creators like taskApiEvents.tasksLoadedSuccess()), which are automatically dispatched back to the store to trigger reducers

Creating Reusable Features

One of the powerful aspects of this architecture is extracting reusable features. For instance, here's a logging feature that could work with any store:

// src/app/stores/shared/with-event-logging.ts
import { inject } from '@angular/core';
import { Events, withEffects } from '@ngrx/signals/events';
import { signalStoreFeature } from '@ngrx/signals';
import { tap } from 'rxjs/operators';

type EventGroup = Record<string, unknown>;
interface EventWithPayload {
  type: string;
  payload?: unknown;
}

/**
 * Creates a store feature that logs all events from specified event groups.
 * Useful for debugging and monitoring event flow.
 */
export function withEventLogging(eventGroups: EventGroup[]) {
  return signalStoreFeature(
    withEffects((store: Record<string, unknown>, events = inject(Events)) => {
      // Collect all events from all groups
      const allEvents = eventGroups.flatMap(group =>
        Object.values(group)
      ) as unknown[];

      return {
        // eslint-disable-next-line @typescript-eslint/no-explicit-any
        logAllEvents$: events.on(...(allEvents as [any, ...any[]])).pipe(
          tap((event: EventWithPayload) => {
            const isError = event.type.includes('Failure');
            if (isError) {
              console.error(`[Store Event] ${event.type}:`, event.payload);
            } else {
              console.log(`[Store Event] ${event.type}`, event.payload);
            }
          })
        ),
      };
    })
  );
}

This feature can be added to any store to get automatic event logging, which would make our life easier when it comes to debugging.

Composing the Store

Now our store becomes a clean composition of features:

// src/app/stores/task-store/task.store.ts
import { signalStore, withState, withComputed, type } from '@ngrx/signals';
import { withEntities } from '@ngrx/signals/entities';
import { computed, inject, Signal } from '@angular/core';
import { Task, TaskStatus } from '../../interfaces/task';
import { TASK_BOARD_INITIAL_STATE } from './task-store.config';
import { withTaskReducer } from './task.reducer';
import { withTaskEffects } from './task.effects';
import { taskPageEvents, taskApiEvents } from './task.events';
import { withEventLogging } from '../shared/with-event-logging';

interface TaskStoreState {
  taskEntities: Signal<Task[]>;
}

export const TaskStore = signalStore(
  { providedIn: 'root' },

  // IMPORTANT: Entities must come before State
  withEntities({ entity: type<Task>(), collection: 'task' }),

  // State
  withState(() => inject(TASK_BOARD_INITIAL_STATE)),

  // Event-driven reducers
  withTaskReducer(),

  // Event-driven effects
  withTaskEffects(),

  // Event logging (for debugging)
  withEventLogging([taskPageEvents, taskApiEvents]),

  // Computed views
  withComputed((store: TaskStoreState) => ({
    tasksTodo: computed(() =>
      store.taskEntities().filter((t: Task) => t.status === TaskStatus.TODO)
    ),
    tasksInProgress: computed(() =>
      store
        .taskEntities()
        .filter((t: Task) => t.status === TaskStatus.IN_PROGRESS)
    ),
    tasksDone: computed(() =>
      store.taskEntities().filter((t: Task) => t.status === TaskStatus.DONE)
    ),
  }))
);

⚠️ Critical ordering note: withEntities() must come before withState(). If we put state first, the entity collection won't be properly initialized.

Configuration Setup

In the initial state we used an injection token pattern for better testability:

// src/app/stores/task-store/task-store.config.ts
import { InjectionToken } from '@angular/core';
import { TaskBoardState } from '../../interfaces/task';

export const TASK_BOARD_INITIAL_STATE = new InjectionToken<TaskBoardState>(
  'taskBoardInitialState',
  {
    providedIn: 'root',
    factory: () => ({
      isLoading: false,
      pageSize: 10,
      pageCount: 1,
      currentPage: 1,
    }),
  }
);

This makes it easy to override the initial state in tests.

Dispatching Events from Components

Now our components can simply dispatch events instead of calling store methods:

// src/app/pages/board/board.component.ts
// ..imports

export class BoardComponent {
  readonly store = inject(TaskStore);
  readonly dispatch = injectDispatch(taskPageEvents);
  readonly TaskStatus = TaskStatus;

  constructor() {
    // Dispatch the 'opened' event when component initializes
    // This triggers the effect to load tasks
    this.dispatch.opened();
  }

  createTask() {
    if (this.taskForm.invalid) return;

    const newTask = {
      title: this.taskForm.get('title')?.value,
      description: this.taskForm.get('description')?.value,
      status: TaskStatus.TODO,
    };

    // Dispatch event: task.effects.ts handles the API call
    // task.reducer.ts updates the store state on success
    this.dispatch.taskCreated(newTask);
    this.taskForm.reset();
  }

  deleteTask(taskId: string) {
    if (confirm('Are you sure you want to delete this task?')) {
      // Dispatch event: handled by effects and reducer
      this.dispatch.taskDeleted(taskId);
    }
  }

  moveTo(taskId: string, targetStatus: TaskStatus) {
    // Dispatch event: optimistic update by reducer
    // Effects handle API call and revert on failure
    this.dispatch.taskStatusChanged({ id: taskId, status: targetStatus });
  }
}

Using injectDispatch() generates type-safe methods for each event in the group. The component doesn't know or care about API calls, error handling, or state mutations — it just describes what the user did in the UI.

Testing Event-Driven Flows

One of the greatest benefits of event-driven architecture is testability. By separating concerns reducers handle state, effects handle side effects, components dispatch events, and we can test each piece in isolation without complex setup or mocking.

Testing Philosophy

The event-driven pattern gives us three distinct testing levels:

Reducer tests: Pure function tests — pass in events, assert on state changes
Effect tests: Observable tests — mock services, dispatch events, assert on service calls
Integration tests: Full store tests — dispatch events, wait for effects, assert on final state

Let's explore each level with our actual working test suite using Vitest.

Testing Reducers

Our reducers are event handler configurations that define how state should be updated in response to events. Therefore, reducer tests should verify that handlers are correctly structured with proper type signatures and return valid state update instructions. Note that actual state mutations will be tested at the store integration level.

describe('Task Reducer', () => {
  describe('Page Events', () => {
    it('should set isLoading to true on page opened', () => {
      const result = on(taskPageEvents.opened, () => ({ isLoading: true }));

      expect(result).toBeDefined();
    });

    it('should update task status optimistically on taskStatusChanged', () => {
      const result = on(
        taskPageEvents.taskStatusChanged,
        (evt: { payload: { id: string; status: TaskStatus } }) =>
          updateEntity(
            { id: evt.payload.id, changes: { status: evt.payload.status } },
            { collection: 'task' }
          )
      );

      expect(result).toBeDefined();
    });
  });

  describe('API Events - Success', () => {
    it('should set all entities and loading to false on tasksLoadedSuccess', () => {
      const result = on(
        taskApiEvents.tasksLoadedSuccess,
        (evt: { payload: Task[] }) => [
          setAllEntities(evt.payload, { collection: 'task' }),
          { isLoading: false },
        ]
      );

      expect(result).toBeDefined();
    });

    it('should add entity on taskCreatedSuccess', () => {
      const result = on(
        taskApiEvents.taskCreatedSuccess,
        (evt: { payload: Task }) =>
          addEntity(evt.payload, { collection: 'task' })
      );

      expect(result).toBeDefined();
    });

    it('should remove entity on taskDeletedSuccess', () => {
      const result = on(
        taskApiEvents.taskDeletedSuccess,
        (evt: { payload: string }) =>
          removeEntity(evt.payload, { collection: 'task' })
      );

      expect(result).toBeDefined();
    });
  });

  // .. more reducer tests
});

Testing Effects

Effect tests should verify that effects respond to events by calling the appropriate service methods. We create a minimal test store, dispatch events, and verify the effect triggers the expected service calls.

describe('loadTasks$ effect', () => {
    it('should call getTasks service method when opened event is dispatched', async () => {
      const mockTasks: Task[] = [
        {
          id: '1',
          title: 'Test Task',
          status: TaskStatus.TODO,
          createdAt: new Date().toISOString(),
        },
      ];
      mockTaskService.getTasks.mockReturnValue(
        of({ tasks: mockTasks, totalPages: 1 })
      );

      const TestStore = signalStore(
        withState({ isLoading: false }),
        withEntities({ entity: type<Task>(), collection: 'task' }),
        withTaskEffects()
      );

      TestBed.configureTestingModule({
        providers: [TestStore],
      });

      const store = TestBed.inject(TestStore);
      const dispatch = TestBed.runInInjectionContext(() =>
        injectDispatch(taskPageEvents)
      );

      dispatch.opened();

      await new Promise(resolve => setTimeout(resolve, 100));

      expect(mockTaskService.getTasks).toHaveBeenCalledWith(1, 10);
    });
});

Key patterns:

Create minimal test stores: We compose a minimal signalStore with only the dependencies needed for the effect being tested (withState, withEntities, withTaskEffects)
Mock service dependencies: Vitest's vi.fn() is being used to mock TaskService methods, with RxJS of() for success cases or throwError() for error scenarios
Dispatch events to trigger effects: We utilize injectDispatch(taskPageEvents) to obtain the dispatch function, then dispatch events and wait for async effects with await new Promise(resolve => setTimeout(resolve, 100))
Verify service calls: Assert that the correct service method was called with expected parameters for both success and error paths, validating that the effect correctly responds to dispatched events

Integration Testing

Integration tests verify the complete event-driven flow by dispatching actual events through injectDispatch and observing that effects trigger service calls. These tests use the full TaskStore composition with all features (entities, state, reducers, effects, computed signals) and mocked services to validate the entire system works together:

// ..imports

describe('Integration: Event Flow', () => {
  let store: InstanceType<typeof TaskStore>;
  let dispatch: ReturnType<typeof injectDispatch<typeof taskPageEvents>>;
  let mockTaskService: {
    getTasks: ReturnType<typeof vi.fn>;
    createTask: ReturnType<typeof vi.fn>;
    deleteTask: ReturnType<typeof vi.fn>;
    updateTaskStatus: ReturnType<typeof vi.fn>;
  };

  beforeEach(() => {
    mockTaskService = {
      getTasks: vi.fn(),
      createTask: vi.fn(),
      deleteTask: vi.fn(),
      updateTaskStatus: vi.fn(),
    };

    TestBed.configureTestingModule({
      providers: [
        TaskStore,
        { provide: TaskService, useValue: mockTaskService },
      ],
    });

    store = TestBed.inject(TaskStore);
    dispatch = TestBed.runInInjectionContext(() =>
      injectDispatch(taskPageEvents)
    );
  });

  describe('Load Tasks Flow', () => {
    it('should dispatch opened event and load tasks through complete flow', async () => {
      // Arrange: Mock service response
      const mockTasks: Task[] = [
        {
          id: '1',
          title: 'Test Task',
          status: TaskStatus.TODO,
          createdAt: new Date().toISOString(),
        },
        {
          id: '2',
          title: 'In Progress Task',
          status: TaskStatus.IN_PROGRESS,
          createdAt: new Date().toISOString(),
        },
      ];
      mockTaskService.getTasks.mockReturnValue(
        of({ tasks: mockTasks, totalPages: 1 })
      );

      // Initial state verification
      expect(store.taskEntities()).toEqual([]);
      expect(store.isLoading()).toBe(false);

      // Act: Dispatch page opened event
      dispatch.opened();

      // Wait for async effects to complete
      await new Promise(resolve => setTimeout(resolve, 100));

      // Assert: Verify complete flow
      expect(mockTaskService.getTasks).toHaveBeenCalledWith(1, 10);
      // Note: State updates happen through reducers responding to API success events
    });

    it('should handle service errors when loading tasks', async () => {
      // Arrange: Mock service error
      mockTaskService.getTasks.mockReturnValue(
        throwError(() => ({ message: 'Network error' }))
      );

      // Act: Dispatch page opened event
      dispatch.opened();

      // Wait for async effects
      await new Promise(resolve => setTimeout(resolve, 100));

      // Assert: Store should remain in safe state
      expect(store.taskEntities()).toEqual([]);
    });
  });
});

Key patterns:

Full store composition: We inject the complete TaskStore with TestBed to test all composed features (entities, state, reducers, effects, computed signals)
Dispatch actual events: We use injectDispatch(taskPageEvents) to dispatch events like dispatch.opened(), dispatch.taskCreated(), etc.
Mock service dependencies and verify calls: vi.fn() is being used to mock TaskService methods, control responses with of() or throwError(), and verify services were called when events are dispatched
Handle async and assert state: We use await new Promise(resolve => setTimeout(resolve, 100)) to allow effects to complete, then verify service calls and state through signals like store.taskEntities() and store.isLoading()

Why This Approach Works

The event-driven architecture makes testing more structured because:

Clear boundaries: Reducers (state updates), effects (side effects), and components (UI/dispatch) have distinct, testable responsibilities
Explicit state changes: All state updates go through events, making the data flow transparent and traceable
Mockable dependencies: Services are injected and easily replaced with mocks in tests
Predictable behavior: Same events with same initial state will always produce the same results

💡 NGRX Signals Events use a configuration-based approach where reducers and effects are declarative instructions rather than directly executable functions. Unit tests verify correct configuration and type safety, while integration tests validate the complete event flow and actual state changes.

When to Use Event-Driven Architecture

Choosing between event-driven and method-based approaches depends on your application's complexity, team expertise, and long-term maintainability needs. Consider these factors when making your decision.

Use event-driven when:

Building medium to large applications with complex state interactions
Multiple features need to react to the same user action or data change
You require centralized logging, monitoring, or error handling across state updates
Working in a team where clear separation between UI, business logic, and side effects improves collaboration

Stick with method-based when:

Building simple features with straightforward CRUD operations
Rapid prototyping where architectural overhead isn't justified yet
Application scope is small and unlikely to grow
Team is new to NGRX Signals

💡 You don't need to choose one approach for your entire application. NGRX Signals enable us to start with method-based stores for simple features and migrate to event-driven architecture as our complexity grows. Many successful applications use both patterns, applying event-driven architecture where it provides the most value and keeping simpler features method-based. The key is understanding the trade-offs and choosing the approach that best fits each specific use case.

Resources

Code for this article: View on GitHub (v2.0.0)
NgRx Signal Store Events documentation
Previous article: Using NgRx Signal Store (method-based approach)

What's your experience with state management? Have you encountered similar implementation challenges?

Let me know in the comments.

Choosing Tech Stack in 2025: A Practical Guide

Dimitris Kiriakakis — Tue, 21 Oct 2025 18:39:16 +0000

With dozens of frameworks competing for attention in 2025, it's easy to get lost in comparisons. In this guide, we'll explore the most relevant options with their advantages and disadvantages, based on technologies I've used in production, so the insights come from my personal hands-on experience rather than theoretical comparisons.

Frontend Stacks
Backend Stacks
Full-Stack Solutions
Decision Framework

Frontend Stacks

React Ecosystem

The React ecosystem remains the dominant force in frontend development. If you're building component-heavy applications or large-scale SPAs, React 19 combined with Next.js 15 gives you a production-ready foundation. The latest version brings Server Components to the forefront, and many other features that have drastically improved developer experience (see my related article).

TypeScript integration has never been better, and the ecosystem around state management has matured significantly. While Redux still has its place, most modern applications benefit from lighter solutions like - my personal favorite - Zustand for global state and TanStack Query for server state. The combination gives you predictable data flow without the ceremony of traditional flux patterns.

Advantages:

Largest talent pool and ecosystem with solutions for virtually any problem
Server Components dramatically reduce client-side JavaScript while maintaining interactivity
Excellent tooling including debugging, IDE extensions, and testing utilities
Strong job market makes React experience a valuable career investment

Disadvantages:

Steep learning curve with Server Components requiring understanding of client/server boundaries
Flexibility means teams spend more time debating architectural decisions
Performance requires deliberate optimization through memoization and careful component design (please be careful while using useEffect)

// Sample Next.js 15 Server Component
export default async function ProductList() {
  const products = await fetch('https://api.example.com/products')
    .then(res => res.json());

  return (
    <div className="grid grid-cols-3 gap-4">
      {products.map(product => (
        <ProductCard key={product.id} product={product} />
      ))}
    </div>
  );
}

Styling in the React world has mainly been around Tailwind CSS, though CSS Modules and styled-components are still helpful. Tailwind's utility-first approach pairs particularly well with component-based architecture, letting you see all your styles inline without context switching.

Angular

Angular has always been the choice for teams that value convention over configuration, and latest versions (v19, v20, and upcoming v21) continue that tradition while modernizing the developer experience (see my related article). The framework provides everything you need out of the box: routing, forms, SSR, testing utilities, and recently Signals, a more intuitive reactivity model that reduces boilerplate.

What makes Angular stand out in 2025 is its commitment to backward compatibility and enterprise features. Large organizations appreciate the opinionated structure that makes onboarding new developers straightforward. The CLI generates consistent code, the dependency injection system keeps code testable, and the built-in SSR and prerendering capabilities mean you don't need additional meta-frameworks.

Advantages:

Batteries-included approach eliminates decision fatigue with consistent, opinionated patterns
First-class TypeScript integration built from the ground up
Rendering flexibility (built-in prerendering, SSR, CSR)
Strong long-term stability backed by Google with guaranteed updates
Angular Material provides production-ready accessible and easy-to-use components

Disadvantages:

Larger bundle sizes compared to React's or Vue's
Steep learning curve with Angular-specific vocabulary and patterns
Smaller ecosystem means fewer third-party solutions than React
Opinionated structure can feel restrictive for teams preferring flexibility

// Angular with Signals
@Component({
  selector: 'app-counter',
  standalone: true,
  template: `
    <button (click)="increment()">Count: {{ count() }}</button>
  `
})
export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(val => val + 1);
  }
}

The new Signals API in Angular offers a simpler alternative to RxJS for basic reactivity, giving teams flexibility and in combination with NgRx Signal Store and upcoming Signal Forms (in v21) they provide you with an end to end, zoneless solution for building stateful UIs.

Vue

Vue 3 with the Composition API strikes a balance between React's flexibility and Angular's structure. The framework prioritizes developer experience without sacrificing power, making it an excellent choice for teams that want rapid development without reinventing patterns on every project.

The Composition API brings TypeScript support that rivals React, while maintaining Vue's approachable single-file component structure. You get the benefits of co-locating template, script, and styles while keeping clear separation between concerns. Nuxt 4 provides the meta-framework capabilities similar to Next.js, with excellent conventions for file-based routing, server-side rendering, and API routes.

Advantages:

Best-in-class documentation making it accessible for all skill levels
Small learning curve with single-file components keeping related code together
Smaller bundle size around 80 KB results in faster initial page loads compared to Angular or React
Progressive adoption path lets you start simple and add complexity only when needed

Disadvantages:

Smaller ecosystem with fewer specialized libraries
Less corporate adoption resulting in fewer large-scale production examples
Fewer Vue positions in the job market compared to Angular or React
TypeScript support improved but not quite as seamless as frameworks built with it from the start

// Vue 3 Composition API with TypeScript
<script setup lang="ts">
import { ref, computed } from 'vue';

interface Product {
  id: number;
  name: string;
  price: number;
}

const products = ref<Product[]>([]);
const total = computed(() => 
  products.value.reduce((sum, p) => sum + p.price, 0)
);

async function fetchProducts() {
  products.value = await fetch('/api/products').then(r => r.json());
}
</script>

Pinia has become the standard for state management, offering a simpler API than Vuex while maintaining TypeScript support and devtools integration. The ecosystem is mature enough for production use but you'll occasionally need to reach for general-purpose JavaScript libraries instead of Vue-specific solutions.

Backend Stacks

Node.js/TypeScript

Running TypeScript on the backend with Node.js 26 gives you code sharing opportunities that other stacks can't match. Share validation schemas between frontend and backend, reuse utility functions, and maintain a single language across your entire stack. This significantly reduces context switching and makes full-stack development more efficient.

NestJS has emerged as the enterprise choice for Node.js backends, bringing Angular-inspired architecture patterns to server-side development. The framework provides dependency injection, decorators for routing, built-in validation, and excellent TypeScript support out of the box. For teams that need less ceremony, Fastify offers better performance with a simpler API, though you'll need to assemble more pieces yourself.

Advantages:

Code sharing between frontend and backend reduces duplication and keeps validation consistent
Enormous ecosystem offering packages for virtually any task (npm)
First-class real-time features through WebSockets and SSE (Server Sent Events) for chat and collaborative applications
High development speed with no compilation required and hot-reloading

Disadvantages:

Performance lags compiled languages with typical response times of 5-20ms versus sub-5ms
Single-threaded nature means CPU-intensive operations require worker threads or offloading
Higher memory usage (on average) when compared to GoLang or Python (see related comparison)
Debugging asynchronous code remains challenging despite tooling improvements

// NestJS Controller with Prisma
@Controller('products')
export class ProductsController {
  constructor(private prisma: PrismaService) {}

  @Get()
  async findAll(): Promise<Product[]> {
    return this.prisma.product.findMany({
      include: { category: true }
    });
  }

  @Post()
  async create(@Body() data: CreateProductDto): Promise<Product> {
    return this.prisma.product.create({ data });
  }
}

When it comes to persistence in the Node.js world, Prisma provides type-safe database access with excellent migration tooling, while Drizzle offers a lighter alternative that generates less code and provides more granular control. Both support PostgreSQL, MySQL, and SQLite, giving you flexibility in database choice.

GoLang

Go has become the go-to choice for microservices and high-performance APIs. The language's simplicity is deceptive because while the syntax is minimal, the standard library is comprehensive. Built-in concurrency primitives through goroutines and channels make writing concurrent code approachable, and the performance is excellent with response times typically measured in single-digit milliseconds.

Echo has emerged as the leading web framework in Go, offering a clean API with excellent performance and middleware support out of the box. The framework provides routing, request validation, middleware composition, and comprehensive documentation while staying lightweight. Echo's design philosophy balances developer experience with performance, making it suitable for everything from simple APIs to complex microservices. Most Go developers find they need less framework than in other languages because the standard library provides so much.

Advantages:

Exceptional performance with response times under 5ms and ability to handle tens of thousands of concurrent connections
Single static binary deployment with no runtime dependencies or version conflicts
Explicit error handling forces consideration of failure cases resulting in robust code
Comprehensive standard library often eliminates need for external dependencies

Disadvantages:

More verbose than dynamic languages requiring explicit error handling
Smaller ecosystem than Node.js or Python particularly for web-specific libraries
Generics feel bolted on rather than integral to language design
Developer velocity slower than interpreted languages due to compilation requirement

// Go with Echo framework
type ProductHandler struct {
    db *gorm.DB
}

func (h *ProductHandler) GetProducts(c echo.Context) error {
    var products []Product
    result := h.db.Preload("Category").Find(&products)

    if result.Error != nil {
        return c.JSON(500, map[string]string{"error": result.Error.Error()})
    }

    return c.JSON(200, products)
}

GORM handles ORM duties with a familiar active record pattern, though many Go developers prefer sqlc which generates type-safe code from SQL queries. This gives you the performance of hand-written SQL with compile-time safety. The approach fits Go's philosophy of explicit over implicit, and the generated code is readable and maintainable.

Python

Python's renaissance in web development comes from FastAPI - my personal favorite nowadays - which brings modern async capabilities and automatic API documentation through Pydantic models. The framework feels designed for 2025, with type hints throughout and excellent developer experience. If your application needs to integrate with machine learning models, data processing pipelines, or scientific computing libraries, Python is often the only practical choice.

Advantages:

Unmatched integration with ML/AI ecosystems through NumPy, TensorFlow, and PyTorch
Automatic API documentation through OpenAPI specifications eliminates separate documentation tools
High development speed due to concise syntax and extensive standard library
Type hints with Pydantic provide runtime validation and excellent editor support

Disadvantages:

Weakest performance with typical response times of 10-30ms (still okay for most use cases)
Global Interpreter Lock prevents true parallelism for CPU-bound tasks
Deployment more complex than compiled languages requiring Python version and dependency management
Dynamic typing can hide errors until runtime despite type hints

# FastAPI with Pydantic
from fastapi import FastAPI, Depends
from sqlalchemy.orm import Session

app = FastAPI()

@app.get("/products", response_model=list[ProductSchema])
async def get_products(db: Session = Depends(get_db)):
    products = db.query(Product).all()
    return products

@app.post("/products", response_model=ProductSchema)
async def create_product(
    product: ProductCreate,
    db: Session = Depends(get_db)
):
    db_product = Product(**product.dict())
    db.add(db_product)
    db.commit()
    db.refresh(db_product)
    return db_product

Django remains relevant for content-heavy applications and admin interfaces. The batteries-included philosophy means you get authentication, admin panels, ORM, and form handling out of the box. For rapid prototyping or building MVPs where you need traditional CRUD operations, Django's productivity is hard to beat.

Full Stack Solutions

The lines between frontend and backend have blurred significantly, with meta-frameworks now providing full-stack capabilities that handle everything from database queries to server-side rendering. These solutions offer compelling productivity benefits by reducing the number of technologies you need to coordinate.

The T3 Stack: Type-Safety First

The T3 stack represents a different philosophy, prioritizing end-to-end type safety over everything else. Built on Next.js, the stack combines tRPC for type-safe APIs, Prisma for type-safe database access, NextAuth.js for authentication, and Tailwind CSS for styling. The result is remarkable: change your database schema, and TypeScript immediately highlights every place in your frontend that needs updating.

Advantages:

End-to-end type safety catches errors at compile time that would otherwise appear in production
Exceptional development experience with autocomplete working across entire application stack
No code generation required for API contracts like GraphQL or OpenAPI
Monorepo structure keeps everything synchronized eliminating version mismatch issues

Disadvantages:

Only works for monolithic applications where frontend and backend share same codebase
Public APIs or microservices architectures don't benefit from tRPC's type sharing
Tight coupling between frontend and backend can make independent scaling difficult
Teams familiar with REST or GraphQL face learning curve with tRPC's procedural approach

// tRPC Router
export const productRouter = router({
  list: publicProcedure
    .query(async ({ ctx }) => {
      return ctx.prisma.product.findMany();
    }),

  create: protectedProcedure
    .input(z.object({
      name: z.string(),
      price: z.number()
    }))
    .mutation(async ({ ctx, input }) => {
      return ctx.prisma.product.create({
        data: input
      });
    })
});

// Type-safe client usage
const products = await trpc.product.list.query();

FastAPI + Angular/Next + Flutter: All platforms included

This one is my personal favorite nowadays (when most projects need to be AI powered), when I cannot commit to coupling between frontend and backend (many developers, different skills, knowledge levels etc). The combination of FastAPI with either Angular or Flutter provides a robust foundation for applications that need to integrate ML models while delivering excellent experiences, on the browser, but also on mobile devices.

FastAPI serves as an ideal backend for AI applications because it handles the Python ML ecosystem naturally while providing modern async capabilities. The automatic API documentation becomes particularly valuable when coordinating between backend teams building models and frontend teams consuming them. Type validation through Pydantic ensures that model inputs and outputs match expectations, catching integration errors early rather than in production.

For the frontend, we can choose between web-first and truly native approaches.

Angular paired with SSR and PWA (Progressive Web App) capabilities delivers a mobile-first web application that works across platforms without separate codebases. The framework's dependency injection makes it straightforward to swap mock ML services during development with real API calls in production. TypeScript flows from the API contracts through to the UI components, providing end-to-end type safety when combined with OpenAPI code generation.

// Angular service consuming FastAPI ML endpoint
@Injectable({
  providedIn: 'root'
})
export class PredictionService {
  constructor(private http: HttpClient) {}

  predictSentiment(text: string): Observable<SentimentResult> {
    return this.http.post<SentimentResult>(
      '/api/v1/predict/sentiment',
      { text }
    );
  }
}

// Component using the service
@Component({
  selector: 'app-sentiment-analyzer',
  template: `
    <textarea [(ngModel)]="inputText"></textarea>
    <button (click)="analyze()">Analyze</button>
    @if (result) {
      <div class="result">
        Sentiment: {{ result.label }}
        Confidence: {{ result.confidence | percent }}
      </div>
    }
  `
})
export class SentimentAnalyzerComponent {
  inputText = '';
  result = signal<SentimentResult | null>(null);

  constructor(private predictionService: PredictionService) {}

  analyze() {
    this.predictionService
      .predictSentiment(this.inputText)
      .subscribe(r => this.result.set(r));
  }
}

Flutter offers an alternative approach when we need truly native performance or access to device-specific features that web APIs don't expose. The Dart language provides strong typing similar to TypeScript, and the framework renders using native components rather than WebView. For AI applications, Flutter's isolates handle background processing without blocking the UI, essential when you're running lighter ML models on-device for offline functionality.

// Flutter consuming FastAPI endpoint
class PredictionService {
  final String baseUrl;

  PredictionService(this.baseUrl);

  Future<SentimentResult> predictSentiment(String text) async {
    final response = await http.post(
      Uri.parse('$baseUrl/api/v1/predict/sentiment'),
      headers: {'Content-Type': 'application/json'},
      body: jsonEncode({'text': text}),
    );

    if (response.statusCode == 200) {
      return SentimentResult.fromJson(jsonDecode(response.body));
    }
    throw Exception('Failed to get prediction');
  }
}

// Flutter widget
class SentimentAnalyzer extends StatefulWidget {
  @override
  _SentimentAnalyzerState createState() => _SentimentAnalyzerState();
}

class _SentimentAnalyzerState extends State<SentimentAnalyzer> {
  final _controller = TextEditingController();
  SentimentResult? _result;

  void _analyze() async {
    final service = PredictionService('https://api.example.com');
    final result = await service.predictSentiment(_controller.text);
    setState(() => _result = result);
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        TextField(controller: _controller),
        ElevatedButton(
          onPressed: _analyze,
          child: Text('Analyze'),
        ),
        if (_result != null)
          Text('Sentiment: ${_result!.label} (${_result!.confidence})'),
      ],
    );
  }
}

Advantages:

Complete platform coverage with specialized tools we get optimal web experience while Flutter provides true native mobile performance, ensuring best-in-class UX on each platform rather than compromising with a single cross-platform solution
Shared backend reduces duplication, the FastAPI backend serves both web and mobile, keeping business logic, ML models, and data access centralized with automatic API documentation
Python's AI/ML ecosystem integration, FastAPI naturally integrates with NumPy, Pandas, TensorFlow, and PyTorch, making it the only practical choice for applications requiring machine learning capabilities
Type safety across platforms, TypeScript in Angular and Dart in Flutter both provide strong typing, with OpenAPI generation ensuring type-safe API contracts between frontend and backend
Independent scaling and deployment. Web and mobile applications can be deployed, scaled, and updated independently based on their specific usage patterns and requirements
Team specialization benefits. This stack enables developers to focus on their strengths (web vs mobile) while sharing the same backend APIs, improving code quality and development velocity in their respective domains

Disadvantages:

Managing three separate codebases (backend, web frontend, mobile frontend) requires more coordination, tooling, and developer expertise across different ecosystems
Team needs proficiency in Python, TypeScript, and Dart, making it harder to share developers across the stack
Keeping web and mobile applications in sync with identical features and UI/UX becomes difficult
Higher deployment and CI/CD complexity. Such a stack requires separate build pipelines, testing strategies, and deployment processes for web (Angular), iOS/Android (Flutter), and backend (FastAPI)
Code duplication. Business logic, validation, and data models often get duplicated between Angular and Flutter despite sharing the same API, increasing maintenance overhead

Decision Framework

Your choice of technology stack should start with your constraints and goals, not with what's trendy. For example, a startup racing to product-market fit has different needs than an enterprise maintaining a decades-old codebase, and both differ from a developer learning web development.

Learning and Side Projects

If you're learning web development or building side projects, pick something with excellent documentation and a large community. Next.js with React offers the largest ecosystem and most learning resources, making it easier to find solutions when stuck. The skills transfer directly to the job market where React dominates.

For backend learning, start with Express or NestJS if you're already comfortable with JavaScript. The mental overhead of learning a new language simultaneously with backend concepts is significant. FastAPI with Python offers an excellent alternative with clear, readable code and automatic documentation that helps you understand how APIs work. Once you're comfortable with backend patterns, exploring Go gives you a compiled language perspective without the complexity of Rust.

Startups and MVPs

Speed to market matters more than technical perfection when validating business ideas. Full-stack frameworks like Next.js let you build features quickly without coordinating separate frontend and backend deployments. The T3 stack's end-to-end type safety catches bugs early, reducing the testing burden when you're moving fast.

As you scale, Next.js provides clear migration paths. Start with Server Components for simple data fetching, add Server Actions for mutations, and extract to separate API services only when you need independent scaling. The framework grows with your application rather than forcing architectural decisions prematurely. FastAPI provides an excellent alternative if your team has Python expertise or needs ML integration, with development speed rivaling Node.js while maintaining good performance.

Enterprise Applications

Large organizations need different things: long-term stability, extensive tooling, clear architectural patterns, and a talent pool for hiring.** Angular**'s opinionated structure makes codebases consistent across teams, reducing the ramp-up time when developers move between projects. The strong typing and dependency injection patterns scale well to hundreds of developers working on the same application.

For backend services, Go provides an excellent balance of performance and maintainability. The explicit error handling and simple syntax make code reviews straightforward, while the performance characteristics handle high load without complexity. Large organizations like Google, Uber, and Docker rely on Go for critical infrastructure. NestJS offers a Node.js alternative that brings Angular's architectural patterns to the backend, making it familiar for teams already using Angular on the frontend.

Conclusion

The best tech stack is the one that lets you ship quality software efficiently while maintaining a good developer experience. In 2025, we're fortunate to have multiple excellent options across the spectrum of languages and frameworks. Your team's existing skills matter more than performance differences. The familiarity and productivity you gain from working with known technologies typically outweighs the theoretical benefits of switching to something new.

That said, don't be afraid to experiment. Start a small project with an unfamiliar stack to understand its strengths and weaknesses. Build a prototype before committing to rewriting production systems. Validate your assumptions with real code rather than architectural diagrams.

The technology landscape will continue evolving, but the fundamental principles remain constant. Choose tools that solve your specific problems, prioritize maintainability over cleverness, and remember that code is written once but read dozens of times.

The best stack is the one that helps your team deliver value to users consistently and sustainably.

What stack are you using in 2025?

Mastering AI-Assisted Software Development: From Prompts to Production-Ready Code

Dimitris Kiriakakis — Mon, 28 Jul 2025 08:06:52 +0000

AI coding assistants like GitHub Copilot have become part of many developers’ daily workflows. But while it's tempting to rely on them for quick progress, unstructured usage often can often lead to technical debt, inconsistent patterns, and maintainability issues.

After working with Copilot in VS Code and Cursor across multiple projects, from frontend apps to backend services, I've found that the key to successful AI-assisted development is the process. When treated like a junior developer who needs examples, guidance, and review, Copilot (or any AI powered IDE) becomes a powerful teammate. This post outlines how to work with AI in a way that leads to consistent, testable, and maintainable code - from setting the right context to validating output and capturing documentation.

Set the Ground Rules: Copilot Instruction Files and Chat Modes

Before prompting Copilot to write code, it’s important to establish how it should behave in our project. Two key features, instruction files and chat modes, allow us to define expectations upfront and guide the AI toward producing consistent, high-quality output.

Instruction Files for Consistency Across Your Codebase

GitHub Copilot supports Markdown instruction files that describe our project’s architecture, naming conventions, code style, and testing strategy. These files reside under the .github/ directory and can be defined at different levels:

.github/copilot-instructions.md applies project-wide
.github/copilot/<path>.md can target specific components, folders or technologies

Each instruction file begins with a frontmatter section to control scope:

---
applyTo: "**"
---

This syntax ensures the file applies to all files in the workspace. You can scope it to specific directories if needed, for example:

---
applyTo: "src/services/**"
---

Or to specific file types, like:

---
applyTo: "**/*.scss"
---

This setup enables us to enforce global standards and localized rules where needed, for example, one set of patterns for our app's architecture within architecture.instructions.md and another one for the styling within styles.instructions.md.

A sample instruction file might look like this:

---
applyTo: "**/*.ts"
---
# Typescript Development Guidelines

## Code Style
- Use async/await for asynchronous operations
- Inject dependencies via constructors
- Use structured logging: info, debug, and error levels
- Define custom error classes for all thrown exceptions

## Service Architecture
- Implement caching for all external API calls
- Keep business logic in services, not controllers
- Use consistent naming conventions across modules

## Testing Strategy
- Unit test every service method
- Mock all external dependencies
- Include both positive and negative test scenarios

If you're looking for reference implementations or ready-to-use templates, the Awesome Copilot repository includes a wide range of instruction file examples for common stacks like Angular, React, NodeJS, Spring Boot, and Go. These community-curated templates are a strong starting point that can be adapted to match your team’s development practices.

For teams using Cursor, there's also a community-maintained set of conventions called Cursor Rules. These rules go beyond Copilot instruction files by defining team-wide AI behaviors and prompting patterns that can be shared, versioned, and enforced across repos. It’s especially useful for organizations aiming to scale AI-assisted development while maintaining code consistency.

Defining Task-Specific AI Behavior with Custom Chat Modes

In addition to instruction files, Copilot in VS Code supports custom chat modes, a powerful way to tailor the assistant’s behavior to your workflow.

A custom chat mode defines a specific context for your interaction with Copilot. For example, you might create a mode for implementation planning, architectural review, or writing test cases. Each mode combines a dedicated instruction set, selected tools, and optionally, a specific model.

This allows us to quickly switch between different working styles without manually configuring each prompt.

Structure of a Custom Chat Mode

Custom chat modes are stored as Markdown files with the .chatmode.md suffix. They should be stored under ./github/chatmodes/. These files contain two main sections:

1. Frontmatter metadata (YAML)

The frontmatter defines how the mode behaves and which tools or models it should use.

---
description: Generate an implementation plan for new features or refactoring existing code.
tools: ['codebase', 'fetch', 'findTestFiles', 'githubRepo', 'search', 'usages']
model: Claude Sonnet 4
---

description: Appears in the chat input placeholder and in the mode dropdown.
tools: List of allowed tools or tool sets for the mode.
model: (Optional) AI model to use. If not specified, the current workspace model will be used.

2. Body instructions

The body contains detailed instructions for the AI to follow while this mode is active. We can also link to project-wide instruction files for consistency.

# Planning Mode Instructions

You are in planning mode. Your task is to generate an implementation plan for a new feature or refactoring task. Do not generate any code.

The output should be a Markdown document that includes the following:

- **Overview**: A short summary of the feature or change
- **Requirements**: Functional and non-functional requirements
- **Implementation Steps**: Ordered tasks needed to build the feature
- **Testing**: List of tests or validation procedures

Chat modes can reference instruction files we've already defined for our project. For example, our planning mode can include a link to .github/copilot-instructions.md, allowing the assistant to retain architectural context while following task-specific behaviors.

If you're using Cursor, custom chat modes are also supported but currently in beta. You can enable this feature by going to:

Settings → Chat → Custom Modes → Enable

Once enabled, Cursor will recognize .chatmode.md files placed in our workspace, and you can switch between modes just like in VS Code.

Establish a Pattern: Show AI What “Good” Looks Like

Once our configuration is in place, the next step is to define the patterns Copilot should follow. If we want consistent, production-ready output, we need to give the assistant a clear idea of what “good” looks like in our codebase.

The best way to do this is by providing a reference implementation directly in our prompt. Instead of describing architecture verbally, let's point to a specific file that follows our standards, for example, a service with caching, error handling, logging, and proper TypeScript typing.

Example prompt:

Using UserService from services/user-service.ts as a reference, create a ProductService that:

- Follows the same structure and logging patterns
- Uses CacheService and Logger as dependencies
- Implements CRUD operations (getProduct, createProduct, updateProduct, deleteProduct)
- Throws ProductNotFoundError and ProductUpdateError where appropriate
- Uses the Product type from models/product.ts

By including a path to an existing file, Copilot can read and infer architectural decisions, naming conventions, and flow. This is far more effective than relying on plain instructions. This approach transforms our codebase into a reusable library of paradigms, enabling Copilot to generate code that fits seamlessly into our architecture.

Integrate Testing Early: Use AI to Validate Behavior

Once our logic is in place, we should turn to testing. Writing tests early helps confirm that AI-generated code behaves as intended, and often surfaces issues that the assistant wouldn't consider. This works especially well when adopting a test-driven mindset: using test creation not just to validate output, but to shape better implementations from the start.

Copilot can generate robust unit tests, especially when the surrounding code follows consistent patterns.

Example prompt:

Write unit tests for ProductService that:
- Cover all CRUD methods
- Mock HttpClient, CacheService, and Logger
- Validate cache usage and error handling
- Simulate network failures and invalid input

Well-written tests can reveal logic gaps, edge cases, or incorrect assumptions that weren’t considered in the initial generation. In that sense, the testing step acts as a design feedback loop, just like in traditional TDD workflows.

If our project already includes test examples, Copilot will typically follow the same structure, using the appropriate test runner (e.g. Jasmine, Jest, or Vitest) and mocking strategy. For even more consistency, we can create a dedicated .chatmode.md for test generation and link it to our project’s instruction file.

Document as You Go: Let AI Capture What Just Happened

Once a feature is implemented, especially if it involved multiple steps, design decisions, or architectural discussions, it’s easy to move on without documenting what was built. This is one of the areas where AI can provide long-term value beyond just writing code.

After working through a complex flow with Copilot, whether it’s a multi-step service, a new API integration, or a configuration for CI/CD we should prompt it to summarize the outcome and generate useful artifacts:

Example prompt after a completed feature:

Based on the previous prompts and responses, generate:
1. A technical summary of the feature we implemented
2. A Postman collection with example requests and environment variables
3. Deployment notes including required environment variables and restart steps

This turns our development chat history into documentation, something that would otherwise take time and often gets skipped.

We can use this approach to generate:

API documentation for newly developed endpoints
Usage examples for internal libraries or components
Onboarding notes for team members picking up a feature
CI/CD environment checklists or step-by-step deployment guides
Postman collections for QA or stakeholder demos, based on the implemented routes

When combined with our custom instruction files and chat modes, we can even standardize the documentation format across your team. For example, a .chatmode.md could define what a deployment guide should include, or how internal libraries should be annotated.

Final Thoughts

AI-assisted development is no longer about novelty, it’s about discipline. With the right structure in place, tools like Copilot and Cursor can accelerate development without compromising quality. But that only happens when we treat AI as a collaborator, not a shortcut.

What makes the difference isn’t the model, it’s the environment we create around it.

Instruction files define the standards.
Chat modes give us workflows repeatability.
Reference patterns guide consistency.
Tests validate assumptions.
And documentation ensures our work is usable and understandable beyond the current commit.

Used this way, AI becomes more than an autocomplete tool. It helps us implement our ideas faster and it frees up time for deeper work, whether that’s architectural thinking, user experience, or team mentorship.

This isn't about replacing developers. It's about enabling them to focus on the work that actually requires their attention.

Using NgRx Signal Store for State Management in Angular

Dimitris Kiriakakis — Mon, 19 May 2025 13:40:10 +0000

NgRx Signal Store is a lightweight and reactive approach to managing state in Angular applications. It integrates seamlessly with Angular’s signal-based reactivity model and removes the need for traditional boilerplate around reducers, selectors, and effects.

We’ve all worked on apps where we don’t necessarily need full-blown reducers, actions, and effects just to handle local or feature-specific state. Signal Store gives us a more compact, declarative way to manage state, while still supporting powerful patterns like entity collections and computed views.

In this post, we’ll walk through a real-world Signal Store in Angular that features a task board. You’ll find the full sample repository linked at the end.

Why Signal Store

NgRx Signal Store is designed to work with Angular's newer primitives like signals, inject(), and computed(). It removes the need for action creators, reducers, and selectors by giving us a compact way to manage state and handle async operations in one place.

What I liked most when using it:

We get fine-grained reactivity without manually subscribing
We can define computed properties with native computed() functions
Everything can be colocated and self-contained in one store class

Overall, this feels much closer to modern Angular and way easier to grasp than traditional NgRx reducer-based stores.

Signal Store structure

A Signal Store is composed of features like withState() for defining reactive state, withEntities() for managing collections, withComputed() for reactive derived values, and withMethods() for exposing actions like fetch or update.

It also supports withHooks() for lifecycle logic, which can be used to automatically trigger actions when the store is initialized (e.g. loading data) or destroyed (e.g. clearing entities or resetting state). This helps us to place such logic directly inside the store, without relying on component-based lifecycles.

So in our case and the task board we needed:

withState() to hold loading, pagination, and config

  withState(() => {
    return inject({ isLoading: false, pageSize: 10, ...});
  }),

withEntities() to manage our collection of tasks

  withEntities({ entity: type<Task>(), collection: 'task' }),

withComputed() to expose filtered views (e.g. todos vs done)

  withComputed(store => {
    return {
      tasksTodo: computed(() => {
        const tasks = store.taskEntities().filter(t => t.status === 'todo');
        return tasks;
      }),
      // .. more views
  })

..and these views evaluate automatically whenever taskEntities() changes.

withMethods() to define actions like fetchTasks, createTask, deleteTask

  withMethods((store, service = inject(TaskService)) => {
    const updateTasks = (tasks: Task[]) => {
      patchState(store, setEntities(tasks, { collection: 'task' }));
    };
    // .. more methods
    return { updateTasks, ... }
  })

withHooks() to fetch tasks on init and reset the store on destroy

  withHooks(store => ({
    onInit() {
      store.fetchTasks();
    },
    // .. more hooks
  })

Store and service separation still makes sense

Even though Signal Store simplifies how we manage state, it doesn’t remove the need for clear separation of concerns.

In this sample project, I used the following pattern:

The store holds all reactive state: task entities, pagination state, loading flags, and computed views.
The service handles data operations: fetching tasks, creating new ones, updating status, deleting.

This split makes it easier to mock data sources, swap backends later, or reuse the service logic elsewhere (e.g. in tests or command-line tools).

Here’s how a store action looks:

async createTask(task: Omit<Task, 'id' | 'createdAt'>) {
  try {
    const newTask = await firstValueFrom(service.createTask(task));
    const currentTasks = store.taskEntities();
    updateTasks([...currentTasks, newTask]);
    return newTask;
  } catch (error) {
    throw error;
  }
},

In the changeTaskStatus method, there's also a small but important detail: we optimistically update the task status in the UI before the request completes. If the backend call fails, we revert the task back to its previous state. This pattern gives the user immediate feedback while still keeping the state consistent.

Real-time logging for store actions

One thing I wanted to include from the start was clear logging around all store actions. Each method in the store logs:

when it starts [Store - Action]
when it completes or fails [Store - Error], [Store - Update]
and when state changes [Store - Selector]

This makes it easier to trace data flow through the app and understand exactly what happens at each step. It also helps when testing or debugging async flows. Seeing the sequence of actions and updates printed in the console gives us a mental model of how the store behaves — especially useful when you're still getting familiar with how Signal Store works, as shown in the attached screenshot.

Testing the store with Vitest

To make sure everything behaves as expected, I wrote a full unit test suite for the store using Vitest.

Some highlights:

The store is created in an Angular test injector using runInInjectionContext
Services are mocked with vi.fn() and tested with observable returns
All core methods (fetchTasks, createTask, deleteTask, changeTaskStatus) are covered
Computed views are tested against sample data

Here’s a condensed look at the test setup:

const mockTasks: Task[] = [/* ... */];

beforeEach(() => {
  mockTaskService = {
    getTasks: vi.fn(),
    createTask: vi.fn(),
    deleteTask: vi.fn(),
    updateTaskStatus: vi.fn(),
  };

  injector = TestBed.configureTestingModule({
    providers: [
      TaskStore,
      { provide: TaskService, useValue: mockTaskService },
      {
        provide: TASK_BOARD_INITIAL_STATE,
        useValue: { isLoading: false, pageSize: 10, pageCount: 1, currentPage: 1 },
      },
    ],
  });

  store = runInInjectionContext(injector, () => new TaskStore());
});

Tests are grouped into:

Initial state assertions
Computed selectors
Async method behavior (success and failure scenarios)

Example: testing status changes:

it('should change task status successfully', async () => {
  mockTaskService.updateTaskStatus = vi.fn().mockReturnValue(of(true));
  await store.changeTaskStatus('1', 'in-progress');
  expect(store.taskEntities().find(t => t.id === '1')?.status).toBe('in-progress');
});

This kind of testing setup gives us confidence when refactoring or extending the store.

Final thoughts

NgRx Signal Store is a solid choice for Angular apps that want fine-grained reactivity without the boilerplate of classic NgRx.

Keeping the store and service logic separate still applies, even in this more modern setup — and combining signals with good testing gives us both power and predictability.

You can find the full repo below. If you're exploring Signal Store or migrating from legacy state management setups, this example might be a good reference.

Code for this article: View on GitHub (v1.0.0)

You can find more information and examples in the official NgRx Signal Store documentation.

CSS techniques every developer should know in 2025

Dimitris Kiriakakis — Wed, 02 Apr 2025 14:30:25 +0000

CSS just keeps getting better.

Last year, I shared some techniques that helped clean up messy stylesheets and selectors that make our life easier. In 2025, the evolution continues, with new CSS features that give us more control and more flexibility.

Whether we're building a design system or just trying to stop fighting with specificity, these updates are worth learning and can change the way we write and organize our styles.

Container Queries

Make components responsive to their surroundings, not just the screen.

What we used to do:
Use global media queries like @media (min-width: 768px) to adapt component layouts. But this tightly couples components to the viewport and often breaks when you reuse them elsewhere (e.g. imagine card used in a side menu, the viewport query wouldn't be really helpful in this case).

What we can do now:
Use container queries to style components based on the size of their parent container, not the viewport.

.card {
  container-type: inline-size;
}

@container (min-width: 500px) {
  .card-content {
    display: flex;
    gap: 1rem;
  }

  .card-content img {
    width: 150px;
  }
}

Why this matters:

We can build reusable components that adapt wherever they’re placed
No need for global overrides or layout assumptions anymore
Perfect for responsive cards, search bars, sidebars, etc.

See related codepen, showing container queries in action, with cards that adapt layout based on their container, not the screen.

Cascade Layers

Organize CSS into predictable zones and stop fighting specificity.

What we used to do:
Rely on naming conventions (like BEM), import order, or even CSS-in-JS to prevent style collisions and unexpected overrides.

What we can do now:
Use @layer to group styles into base, components, and utilities, and control how they override each other.

@layer base {
  body {
    font-family: system-ui, sans-serif;
  }
}

@layer components {
  .button {
    padding: 1rem 2rem;
    color: white;
    background: black;
  }
}

@layer utilities {
  .text-red {
    color: red;
  }
}

/** in this case the utilities layer will have the highest specificity and the base layer the lowest **/
@layer base, components, utilities;

Why this matters:

No more “why is this class overriding my component?”
Layers give us full control over the cascade, even if multiple classes have the same specificity
Works great with design systems or utility-first frameworks like Tailwind

See related codepen, showing cascade layers in action, where utility and component classes clash and @layer makes it crystal clear who wins and why.

The @property Rule

Typed custom properties with better browser support.

What we used to do:
Use --variables, but without type safety, defaults, or animation support.

What we can do now:
Use @property to define typed, animatable custom properties:

@property --angle {
  syntax: '<angle>';
  initial-value: 0deg;
  inherits: false;
}

.loader {
  transform: rotate(var(--angle));
}

This is especially useful for CSS-driven animations and custom design tokens that need to interpolate smoothly (e.g., colors, angles, numbers).

Animation Composition

Combine multiple animations with smooth custom control.

What we used to do:
Avoid animating transform in multiple keyframes, since one would override the other. And animate custom props only in JS or preprocessors.

What we can do now:
Use @property to define a CSS variable, and animation-composition to additively apply multiple transform effects at once:

@property --rotation {
  syntax: "<angle>";
  initial-value: 0deg;
  inherits: false;
}

.spinner {
  --rotation: 0deg;
  width: 100px;
  height: 100px;
  margin: 2rem auto;
  background: hotpink;
  border-radius: 50%;
  display: flex;
  align-items: center;
  justify-content: center;
  color: white;
  font-weight: bold;
  animation: spin 2s linear infinite, pulse 2s ease-in-out infinite;
  animation-composition: add;
}

@keyframes spin {
  to {
    transform: rotate(360deg);
  }
}

@keyframes pulse {
  0%,
  100% {
    transform: scale(1);
  }
  50% {
    transform: scale(1.2);
  }
}

See it in action. This setup allows:

spin to animate a custom angle via --rotation
pulse to scale the element independently
Both animations to be layered together without interfering

It’s clean, performant, and unlocks more expressive animations, without needing any JS to glue it together.

Text-wrap: balance

Smarter, cleaner line breaks for headings.

What we used to do:
Manually adjust line breaks or max-width to prevent awkward wrapping in headings.

What we can do now:
Let the browser do it for us with one line of CSS:

h2 {
  text-wrap: balance;
}

It balances multi-line headings automatically, making them more readable across devices. This is especially useful for hero sections, card titles, and headlines.

Fully supported in all major browsers since 2024.

See related codepen, within the cards there are balanced and unbalanced headings, so you can notice the difference.

Final thoughts

In 2025, CSS is moving from workarounds to purpose-built solutions:

Container queries unlock true layout flexibility.
Cascade layers allow us to define a clear specificity order.
Animation composition, and typed properties are making styles more expressive and reusable.
Text balancing improves our UX with zero effort.

These aren't just nice-to-haves, they're tools you should start using today in your CSS.

Which feature are you most excited to try out?

Building Accessible Web Applications: A Practical Guide for EAA Compliance

Dimitris Kiriakakis — Mon, 03 Mar 2025 10:13:07 +0000

Web accessibility is no longer just a best practice, it has now become a legal requirement in the European Union. With the European Accessibility Act (EAA) setting clear expectations for digital accessibility, developers must ensure their applications are inclusive for all users.

In this post, we’ll break down what EAA compliance means for developers, the legal risks of non-compliance, common accessibility (often abbreviated to A11y) mistakes, and practical steps to build better, more inclusive applications. We will review some A11y friendly libraries for modern frameworks and in the end you will get a repository that contains accessible web development practices in action.

Who needs to comply with the EAA?

The European Accessibility Act (Directive (EU) 2019/882) applies to companies that provide digital products and services in the EU. The deadline to comply is June 2025. The law covers:

E-commerce platforms: Online stores and digital marketplaces
Banking and financial services: Mobile banking apps, payment gateways
Streaming and media services: Video-on-demand platforms, digital libraries
Public sector and essential services: Government portals, healthcare websites
Software and SaaS products: Enterprise applications, productivity tools

Are there exemptions?
Micro-businesses (fewer than 10 employees and less than €2 million annual turnover) may be exempt, however accessibility improves user experience and market reach for all companies.

Legal consequences of non-compliance

Failing to meet EAA accessibility requirements comes with the following risks:

Fines and sanctions: Each EU country can enforce penalties, which can be costly.
Legal challenges: Consumers and advocacy groups can take legal action.
Market restrictions: Non-compliant services may be blocked from operating in the EU.

Beyond the legal aspect, inaccessible websites exclude millions of users and hurt usability for everyone. Again, addressing accessibility early on, prevents compliance issues and improves user experience for everyone.

Common accessibility mistakes (and how to fix them)

We developers, often make accessibility mistakes without realizing it. Below, we will outline common use cases and how to make them compliant and more accessible, categorized into must-have fixes for compliance and nice-to-have improvements for better usability.

Must-Haves: Essentials for accessibility compliance

1. Ensuring the page head is accessible

The <head> section of an HTML document is often overlooked, but it plays a crucial role in accessibility.

Must-have elements in the <head> section:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="description" content="An example of an accessible webpage compliant with the European Accessibility Act.">
    <title>Accessible Webpage Example</title>
    <link rel="stylesheet" href="styles.css">
</head>

lang="en" on <html> – Specifies the primary language for screen readers.
Descriptive <title> – Helps users (especially those using screen readers) understand the page's purpose.
meta name="description" – Provides context when the page appears in search results.
meta name="viewport" – Ensures proper scaling and readability on mobile devices.

2. Using aria-labelledby for section headings

Screen readers should clearly associate form groups and section headings with their related content.

Correct usage:

<section id="contact" aria-labelledby="contact-heading">
    <h2 id="contact-heading">Contact Us</h2>
    <form>
       ...
    </form>
</section>

aria-labelledby="contact-heading" – Ensures screen readers associate the heading with the section.

3. Adding proper labels and ARIA attributes to forms

Forms without labels are confusing for screen reader users because they don’t provide context for input fields. Additionally, users need real-time feedback when errors occur.

Example:

<input type="text" placeholder="Enter your name">

Accessible implementation:

<label for="name">Name:</label>
<input 
  type="text" 
  id="name" 
  name="name" 
  placeholder="Enter your name" 
  required 
  aria-invalid="false"
  aria-describedby="name-error">
<span id="name-error" class="error-message" aria-live="polite"></span>

aria-invalid="false" – Indicates that the field is valid (should be set to "true" when an error occurs).
aria-describedby="name-error" – Links the input field to an error message.
aria-live="polite" – Ensures error messages are announced dynamically by screen readers.

Handling validation dynamically with VanillaJS:

const nameInput = document.getElementById("name");
const nameError = document.getElementById("name-error");

nameInput.addEventListener("input", () => {
    if (nameInput.value.trim() === "") {
        nameInput.setAttribute("aria-invalid", "true");
        nameError.textContent = "Name is required.";
    } else {
        nameInput.setAttribute("aria-invalid", "false");
        nameError.textContent = "";
    }
});

4. Important state changes announcements

Users should be informed about important state changes on the UI, for instance whether their password is currently visible or hidden.

Common use case:

<input type="password" id="password">
<button onclick="togglePassword()">Show</button>

Accessible implementation:

<label for="password">Password:</label>
<div style="position: relative;">
    <input 
        type="password" 
        id="password" 
        name="password" 
        required 
        aria-invalid="false" 
        aria-describedby="password-visibility">
    <button 
        type="button" 
        id="toggle-password-visibility" 
        aria-label="Show password">
        Show
    </button>
</div>
<span id="password-visibility" class="visually-hidden" aria-live="polite">
    Password is currently hidden.
</span>

VanillaJS to update the state dynamically:

const passwordField = document.getElementById("password");
const toggleButton = document.getElementById("toggle-password-visibility");
const visibilityMessage = document.getElementById("password-visibility");
toggleButton.addEventListener("click", () => {
    const isPasswordVisible = passwordField.type === "text";
    passwordField.type = isPasswordVisible ? "password" : "text";

    toggleButton.textContent = isPasswordVisible ? "Show" : "Hide";
    visibilityMessage.textContent = isPasswordVisible 
        ? "Password is currently hidden." 
        : "Password is currently visible.";
});

This ensures that screen readers will announce the password state change properly.

5. Providing visible focus indicators

Keyboard users need to see where their focus is, but sometimes we remove default focus styles for aesthetic reasons.

Common mistake:

button:focus {
  outline: none;
}

Correct usage:

button:focus {
  outline: 3px solid #ffcc00;
}

For a better visual experience, we could as well use :focus-visible to make focus styles appear only when navigating via keyboard:

button:focus-visible {
  outline: 3px solid #ffcc00;
}

6. Missing or incorrect alt text for images

Screen readers rely on alt attributes to describe images to visually impaired users. Without them, images are either ignored or announced as "image," providing no useful context.

Common mistake:

<img src="team.webp">

Correct usage:

<img src="team.webp" alt="A diverse team of eight people smiling in an office">

If an image is decorative and does not add meaningful content, use alt="" so screen readers ignore it.

7. Providing video captions for multimedia content

Video content must include captions to ensure accessibility for users who are deaf or hard of hearing.

Incorrect usage:

<video controls>
  <source src="intro.mp4" type="video/mp4">
</video>

Correct usage:

<video controls>
  <source src="intro.mp4" type="video/mp4">
  <track src="captions.vtt" kind="subtitles" srclang="en" label="English">
</video>

You can find an example of a captions file here.

8. Ensuring keyboard navigation support

Native interactive elements like <button>, <a href="">, <input>, <select>, and <textarea> are automatically focusable and included in the natural tab order. So we would not need to add tabindex to a <button>, since it is already keyboard-focusable.

However, in case we would need to make non-interactive elements like <div>, <span>, or <p> keyboard-focusable, we would need to use tabindex=n.

Example:

<span 
    role="button">
    I am a custom button!
</span>

Accessible implementation:

<span 
    role="button" 
    tabindex="0">
    I am a custom button!
</span>

Here, a static HTML element (<span>) is used to mark up the control, and is exposed as such to assistive technologies through the application of role="button". However, because it is marked up using a <span> element, it won't be focusable without tabindex="0".

Nice-to-haves: Further enhancements

1. Announcing state changes with ARIA live sections

For example, users should receive feedback when a form submission succeeds or fails.

Use case:

<p id="form-status">Form submitted successfully!</p>

Accessible implementation:

<!-- idle state -->
<p id="form-status" role="status" aria-live="polite"></p>

<!-- when form has been submitted -->
<p id="form-status" role="status" aria-live="polite">
  Form submitted successfully!
</p>

aria-live="polite" – Ensures the message is announced by screen readers. When aria-live's attribute is set to polite, assistive technologies will notify users of updates but generally do not interrupt the current task, with the updates having a low priority. When set to assertive, assistive technologies immediately notify the user, potentially clearing the speech queue of previous updates.
role="status" – Indicates that this element provides status updates.

2. Reducing motion for users with vestibular disorders

Animations can cause discomfort for users sensitive to motion.

Correct approach:

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none;
    transition: none;
  }
}

This respects the user’s system settings for reduced motion.

Accessibility-friendly libraries and tools in modern frameworks

Angular

For Angular applications, consider using:

@angular/cdk/a11y – In latest Angular versions the Component Development Kit (CDK) includes the a11y package. We can find some useful examples and usages at the official documentation.
Angular Material — All Material components follow accessibility best practices.

React

For React applications, these libraries can prove really helpful:

@react-aria (Adobe’s React Aria) – Provides UI primitives that enable us to build accessible components.
React Helmet — Helps manage document structure and metadata for screen readers e.g. provide a unique title for each page or view.

Testing & Validating Accessibility

To ensure and maintain accessibility, our websites should be tested using a combination of automated tools and real user feedback.

1. Automated Testing

Lighthouse (Chrome DevTools): With the accessibility report we can run audits to detect WCAG violations.
axe DevTools (Browser Extension): Provides detailed accessibility reports.

2. Screen Reader Testing

VoiceOver (Mac) — Press CMD + F5 to activate.
NVDA (Windows) — Free and widely used screen reader.

3. Keyboard Navigation Testing

Use TAB and SHIFT + TAB to navigate through your websites and your forms.
Ensure all interactive elements are accessible and state changes are being announced.

4. User Testing

Test with different accessibility settings (high contrast mode, reduced motion).
Engage users with disabilities for real-world feedback.

Final Thoughts: Accessibility as a Continuous Effort

Accessibility isn’t a single task, it should be an ongoing commitment to creating better digital experiences for everyone.

Start with must-have fixes to meet compliance requirements.
Implement nice-to-have improvements to enhance usability.
Continuously test and iterate to maintain accessibility standards.
By prioritizing accessibility, we can build applications that are not only legally compliant but also more inclusive and user-friendly.

In case you are looking for more real-world examples, I’ve recently put together a repository that contains accessible web development practices in action.

dimeloper / eaa-compliance-examples

This repository contains examples of accessible web development practices to help developers comply with the European Accessibility Act (EAA).

EAA Compliance Examples

This repository contains examples of accessible web development practices to help developers comply with the European Accessibility Act (EAA). The examples demonstrate techniques for creating inclusive, user-friendly webpages for all users.

Features

Keyboard Accessibility: Includes skip links and focus indicators.
Accessible Forms: Dynamically validates inputs with error messages announced to assistive technologies.
Password Field Enhancements: Visibility toggle with live announcements and error handling.
Multimedia Accessibility: Provides captions for videos and alt text for images.
Semantic HTML: Uses appropriate elements for structure and navigation.
Live Regions: Dynamic updates for screen readers using ARIA.

File Structure

eaa-compliance-examples/
├── index.html           # Main HTML document
├── styles.css           # External CSS for styling
├── script.js            # JavaScript for form interactions
├── captions/
│   └── captions.vtt     # Example captions file for the video
├── intro.mp4            # Introductory video showcasing inclusivity
├── README.md            # Documentation for the

…

View on GitHub

Angular 19: Updating our projects and harnessing its latest features

Dimitris Kiriakakis — Thu, 16 Jan 2025 13:10:01 +0000

The Angular team recently released version 19 and this version introduces various features that improve developer experience as well as performance. In this post, we'll take a look at the key updates and we will review some examples that showcase how to benefit from these features in our own Angular applications.

In case you want to see these features in action, in the end of this article you will also find the link to a Pull Request, that I prepared in order to update my own angular-optimization project to version 19.

Updating our project

As with every version update we can make use of the CLI update command to kick off our project update as such:

ng update @angular/cli @angular/core

Keep in mind that in version 19 all components are standalone by default, so we no longer need standalone: true to declare a component as standalone. In order to migrate our project there is a related migration provided:

ng generate @angular/core:standalone

As part of the migration we can migrate our components to standalone, cleanup unused NgModules and bootstrap our app using standalone APIs. Once we're done we can enforce the standalone API in our project by enabling the related compiler flag in our tsconfig.json.

{
  "angularCompilerOptions": {
    "strictStandalone": true
  }
}

In version 19 we also got migrations to convert constructor-based injection in our classes to use the inject function instead, to clean up all unused imports within our project and to convert eagerly loaded component routes to lazy loaded routes.

ng generate @angular/core:inject
ng generate @angular/core:cleanup-unused-imports
ng generate @angular/core:route-lazy-loading

Please use the last one with caution, as by default it will convert all your component routes to lazy loaded routes (you might still want to eagerly load some of them).

Key Features to Explore

Here are some of the major features introduced in Angular 19 that you can leverage in your projects:

1. Enhanced Server-Side Rendering (SSR) with Server Routes Configuration

Angular 19 enhances server-side rendering by allowing developers to configure how different routes are rendered. You can specify whether a route should be prerendered, server-side rendered, or client-side rendered and resolve route parameters during prerendering.

Example: A sample server routes configuration

import { RenderMode, ServerRoute } from '@angular/ssr';

export const routes: ServerRoute[] = [
  {
    path: '', // This page is static, so we prerender it (SSG)
    renderMode: RenderMode.Prerender,
  },
  {
    path: 'post/:id', // These pages will be prerendered (SSG), but we make use of a parameter to render them
    renderMode: RenderMode.Prerender,
    async getPrerenderParams() {
      const dataService = inject(DataService);
      const ids = await dataService.getIds(); // Assuming this returns ['1', '2', '3']
      return ids.map(id => ({ id })); // Transforms IDs into an array of objects for prerendering
      // This will prerender the paths: `/post/1`, `/post/2` and `/post/3`
    },
  },
  {
    path: 'blog', // This renders the blog page on the server (SSR)
    renderMode: RenderMode.Server,
  },
  {
    path: '**', // This renders the rest of the pages on the client (CSR)
    renderMode: RenderMode.Client,
  },
];

By configuring server routes, we can optimize loading times and improve SEO, as we might need to render our content before it reaches the client.

2. Signal-Based Resource API

One of the standout features of Angular 19 is the introduction of the signal-based resource API. This allows developers to manage application state and HTTP requests more effectively with signals, providing a reactive paradigm for state management.

Example: Making use of the signal-based resource API

import { signal, resource } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class DataService {
  private paramsSignal = signal({ limit: 20, offset: 0 });

  // Resource for fetching data
  dataResource = resource<DataResponse, { limit: number; offset: number }>({
    request: this.paramsSignal,
    loader: async (params) => {
      const { limit, offset } = params.request;
      const response = await fetch(`/api/data?limit=${limit}&offset=${offset}`);
      return await response.json();
    },
  });

  // Method to update parameters
  updateParams(limit: number, offset: number) {
    this.paramsSignal.set({ limit, offset });
  }
}

By utilizing the newly introduced signal based resource API, we now have a seamless way to make our component signals interact with external APIs.

3. View Transitions with withViewTransitions

Another exciting feature in Angular 19 is support for view transitions using the withViewTransitions API. This enables smoother transitions between routes by running the route activation and deactivation inside document.startViewTransition. It enhances user experience by providing visually appealing navigation.

Example: Enabling View Transitions

import { bootstrapApplication } from '@angular/platform-browser';
import { provideRouter } from '@angular/router';
import { AppComponent } from './app.component';
import { appRoutes } from './app.routes';

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(appRoutes, withViewTransitions())
  ]
});

After we enable view transitions on our project, we will be able to experience them when navigating from any route to another one.

4. Incremental Hydration (Developer Preview)

Version 19 brings Angular server-side rendering to another level with incremental hydration. Incremental hydration allows us to annotate parts of our template, using the already familiar @defer syntax, instructing Angular to load and hydrate them on specific triggers, lazily.

Example: Enabling incremental hydration

import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';

// ...
provideClientHydration(withIncrementalHydration());

Example: Making use of incremental hydration

@defer (hydrate on viewport) {
  <blog-post/>
}

When our app loads, Angular will not download and hydrate the blog-post component until it enters the viewport.

Dev Server Updates (HMR)

Angular v19 supports hot module replacement (HMR) for styles out of the box and enables experimental support for template HMR.

Prior to this improvement, every time we changed the style or template of a component and saved the file, the Angular CLI would rebuild our app and send a notification to the browser which would refresh.

The new HMR will compile the style or template we modified, send the result to the browser, and patch our app without a page refresh. Hot module replacement for styles is enabled by default in v19, while we can try HMR for templates by running NG_HMR_TEMPLATES=1 ng serve.

Update and new features in action

I recently updated my angular-optimization project to version 19 as part of a Pull Request where you can see the update process, as well as real-life examples of utilizing the latest features:

Update to angular v19 and utilise resource API #9

dimeloper posted on Dec 09, 2024

Overview

This pull request updates the Angular version to v19 and utilizes most of the newly introduced features as well as showcases the new Angular signal-based resource API for fetching request data.

Key Changes

Updated Angular version to v19.0.4.
Migrated to inject syntax for services and signal based inputs
Introduced the newly introduced, signal based resource API for data fetching in pokemon.service.ts.
Updated imports in several components utilising the unused import notifications.
Migrated to the new server routing configuration in app.config.server.ts and defined rendering modes for available routes.
Adapted server.ts to enable Netlify edge functions support for SSR
Added in-memory scrolling configuration in the app/config.ts and enabled view transitions.
Adjusted angular.json configuration to align with latest v19 standards.

Implementation Details

The Angular version was updated by modifying the package.json and pnpm-lock.yaml files. The angular.json file was updated to reflect changes in the Angular build system and to specify SSR rendering modes for different routes. The resource API in pokemon.service.ts is now used to fetch Pokemon data. This provides efficient and type-safe data fetching. The app.config.server.ts file was altered to utilise the newly introduced server routes (in version 19) that enable defining the rendering mode for each route. that leverages the resource API. Within the server.ts there was also some more adaptations to support Netlify edge functions for server side rendering.

Breaking Changes & Dependencies

None

Additional Notes

None

View on GitHub

Conclusion

Upgrading to Angular 19 provides a variety of new features that can greatly benefit our applications. By exploring these enhancements, we can improve the performance, usability, and maintainability of our Angular projects.

Don't hesitate to check out the official Angular documentation for more detailed insights on these features and if you have any questions or need assistance with your upgrade, feel free to reach out to me.

Happy coding!

Git made simpler: Some modern alternatives to classic commands

Dimitris Kiriakakis — Tue, 26 Nov 2024 12:29:28 +0000

Git is a powerful tool, but it hasn’t always been the most intuitive. Some commands, like git checkout try to do too many things at once, which can lead to confusion, even for experienced developers. To address this, Git introduced in latest versions new commands like git switch and git restore, splitting the functionality of git checkout into more focused pieces. In this post, we’ll explore these and other modern Git commands that can help us work more confidently and efficiently.

From `git checkout` to `git switch` and `git restore`

For years, git checkout was a generic command for switching branches or restoring files. While it worked, its dual purpose often caused confusion. With Git 2.23, git switch and git restore were introduced to split these tasks into two more specialised commands.

git switch: This command is for switching branches only. It makes it clear that we’re changing context to work on a different branch.
git restore: This command is for restoring files from another branch, commit, or stash. It helps us reset or recover files without the risk of unintentionally switching branches.

Why the change?

The Git team realised that having one command do two very different things was a frequent source of errors. As the commit message introducing git switch explained:

git checkout doing too many things is a source of confusion for many users (and it even bites old-timers sometimes).

Examples:

Switching to a branch:

git switch feature-branch

Restoring a file:

git restore component.js

Previously, both tasks would have been done using git checkout, like this:

git checkout feature-branch
git checkout main -- component.js

By separating these commands, Git makes it easier to understand exactly what we're doing.

When to use them:

Use git switch to change branches.
Use git restore to reset or recover specific files without altering our branch.

Managing Changes: `git stash` → `git worktree`

If you’ve ever needed to temporarily save changes, you’ve probably used git stash. While useful, it’s not always the most efficient way to handle working on multiple branches.

Why use `git worktree`:

Instead of stashing changes to switch branches, we can use git worktree to create additional working directories for different branches. This enables us to work on multiple branches simultaneously without losing context or worrying about overwriting changes.

Examples:

Let’s say we're working on main and then we need to check something on feature-branch. With git stash, the process would look like this:

git stash
git checkout feature-branch
# Work on feature-branch
git checkout main
git stash pop

With git worktree, it’s much simpler:

git worktree add ../feature-branch feature-branch

This will create a new directory ../feature-branch on the same level with our project directory, where we can work on feature-branch without disrupting our changes on main. Once we are done with our changes there we can push them on feature-branch and then delete the ../feature-branch directory.

When to use it:

When working on multiple branches in parallel.
When we want a cleaner way to manage changes without constantly stashing and popping.

Undoing Changes: `git reset` → `git restore`

git reset is a powerful command, but its ability to modify both the commit history and the working directory makes it risky for undoing simple changes.

Why use `git restore`:

git restore focuses only on the working directory, making it a safer choice for discarding uncommitted changes.

Examples:

Let’s say we made changes to file.html but we now want to discard them.

With git reset, we would use:

git reset HEAD file.html

This works, but it also interacts with the staging area. A simpler and safer option is:

git restore file.html

When to use it:

Use git restore to undo changes in our working directory.
Save git reset for more advanced tasks like rewinding our commit history.

Simplify Status Checks: `git status` → `git status -sb`

git status gives a detailed view of our repository, but the default output can be overwhelming.

Why use `git status -sb`:

This shorthand provides a cleaner and more compact overview of our repository’s status.

Examples:

The regular git status might output:

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   file1.txt
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   file2.txt

Using git status -sb simplifies the output to:

## main
M file1.txt
M file2.txt

When to use it:

Anytime we want a quick and concise summary of our repository.

Cleaner Pulls: `git pull` → `git pull --rebase`

git pull is a common way to fetch and merge changes from a remote repository. However, it often results in extra merge commits, making our history harder to read.

Why use `git pull --rebase`:

This option applies remote changes on top of our local commits, creating a cleaner, linear history.

Examples:

With a regular git pull, we might see:

* Merge branch 'main' of origin/main
* Our commit
* Remote commit

Using git pull --rebase:

* Our commit
* Remote commit

Save the trouble of typing `--rebase` every time:

We can configure Git to always rebase when pulling by setting the pull.rebase option globally:

git config --global pull.rebase true

With this setting, every git pull will automatically use --rebase, ensuring a consistent and tidy commit history.

When to use it:

When we want to avoid unnecessary merge commits.
Particularly helpful in collaborative projects where clean history matters.

Why these modern commands matter

The newer Git commands like git switch, git restore, and git worktree are about reducing confusion and making git easier to learn and use. By focusing on specific tasks, these commands help us avoid mistakes and keep our workflow organised.

If you’re still using the older commands, don’t worry, they’re not going anywhere. But trying these modern alternatives could make your git experience smoother and more intuitive.

What’s your favourite git tip or trick? Share it in the comments below, I’d love to hear how you’re using Git in your projects!

What's New in Next.js 15: New Hooks, Turbopack and more

Dimitris Kiriakakis — Wed, 23 Oct 2024 14:27:50 +0000

Next.js has consistently pushed the boundaries of modern web development, and with version 15, they've introduced some nice features that improve both performance and the developer experience.

Let’s take a closer look at some of the most impactful updates with some example usages.

In the end of this article you will also get a Next.js v15 starter repository with detailed example usages, if you want to skip to the repo, just scroll to the bottom.

Full Support of React 19 with New Hooks

With Next.js 15, we now get full support for React 19, enabling its new features like the additional hooks. Let’s break down the most notable ones:

useActionState: This hook helps manage and display the state of ongoing actions in our UI (see full example under react-19-hooks/action-state).

const submitActionWithCurrentState = async (
  prevState: any,
  formData: FormData
) => {
  // do some action like adding the user into the users array
};

export default function ActionStateComponent() {
  const [state, formAction] = useActionState(submitActionWithCurrentState, {
    users: [],
    error: null,
  });

  return (
    <div>
      <h1>useActionState Example</h1>
      <form action={formAction} id="action-hook-form" className="mb-4">
        <div>
          <input
            type="text"
            name="username"
            placeholder="Enter your name"
          />
          <button
            type="submit"
          >
            Submit
          </button>
        </div>
      </form>
      <div>{state?.error}</div>
      {state?.users?.map((user: any) => (
        <div key={user.username}>
          Name: {user.username} Age: {user.age}
        </div>
      ))}
    </div>
  );
}

useFormStatus: Ideal for tracking form submission states in real time. For example we can disable the button while our form is being submitted (see full example under react-19-hooks/use-form-status).

const Form = () => {
  const { pending, data } = useFormStatus();

  return (
    <div>
      <input
        type="text"
        name="username"
        placeholder="Enter your name"
      />
      <button
        disabled={pending}
        type="submit"
      >
        Submit
      </button>
      {pending && (
        <p>Submitting {data?.get('username') as string}...</p>
      )}
    </div>
  );
};

useOptimistic: Perfect for handling optimistic updates, allowing the UI to update instantly while a request is still in progress (see full example under react-19-hooks/use-optimistic).

const submitTitle = async (formData: FormData) => {
  // Simulate server delay
  await new Promise(resolve => setTimeout(resolve, 1000));
  const newTitle = formData.get('title') as string;
  if (newTitle === 'error') {
    throw new Error('Title cannot be "error"');
  }
  return newTitle;
};

export default function OptimisticComponent() {
  const [title, setTitle] = useState('Title');
  const [optimisticTitle, setOptimisticTitle] = useOptimistic(title);
  const [error, setError] = useState<string | null>(null);
  const pending = title !== optimisticTitle;

  const handleSubmit = async (formData: FormData) => {
    setError(null);
    setOptimisticTitle(formData.get('title') as string);
    try {
      const updatedTitle = await submitTitle(formData);
      setTitle(updatedTitle);
    } catch (e) {
      setError((e as Error).message);
    }
  };

  return (
    <div>
      <h1>useOptimistic Example</h1>
      <h2>{optimisticTitle}</h2>
      <p> {pending && 'Updating...'} </p>
      <form action={handleSubmit}>
        <input
          type="text"
          name="title"
          placeholder="Change Title"
        />
        <button
          type="submit"
          disabled={pending}
        >
          Submit
        </button>
      </form>
      <div>{error && error}</div>
    </div>
  );
}

Updated Caching Strategies

The Next.js team took developer feedback seriously when refining the caching system. Here's what changed:

No More Automatic Caching for fetch and Route Handlers: To provide more predictable behaviour, fetch requests and route handlers are no longer cached by default. fetch requests will use the no-store strategy by default. To cache them from now onwards, we'll need to include explicit cache parameters.

For example:

async function getData() {
  const res = await fetch('https://api.dimeloper.com/', { cache: 'force-cache' });
  return res.json();
}

Client Router Caching Adjustments: Page components are no longer cached by default in the client router, which prevents potential issues when users expect real-time data updates. In v15 the client will always fetch the latest page component data during in-app navigation.

To retain the original caching behavior in Next.js 15, we can configure it manually as such:

// Next.js 15, next.config.js
module.exports = {
  experimental: {
    staleTimes: {
      dynamic: 30, // Manually set dynamic route staleTime to 30 seconds
      static: 180
    },
  },
};

Asynchronous Request-Specific APIs

A significant improvement is that request-specific APIs like headers, cookies, params, and searchParams are now asynchronous. For example in the search page that we want to render content depending on the searchParams we need to do the following (see full example within search/page.tsx):

export default async function SearchPage({
  searchParams,
}: {
  searchParams: { query: string };
}) {
  const params = await searchParams;

  const query = params.query;

  return (...)
}

Introducing the New `<Form>` Component

Forms are a crucial part of any web app, and Next.js 15 introduces the <Form> component to streamline form functionality. Extending the traditional HTML <form> element, this component brings prefetching, client-side navigation, and progressive enhancement into the mix.

Here’s how it works (see full example within form-showcase/page.tsx):

export default function FormPage() {
  return (
    <div>
      <h1>Next v15 Form Component</h1>
      <p>Which saves us from a lot of boilerplate code.</p>
      <Form action="/search">
        {/* On submission, the input value will be appended to 
            the URL, e.g. /search?query=abc */}
        <input
          name="query"
          placeholder="Enter your search query"
        />
        <button
          type="submit"
        >
          Submit
        </button>
      </Form>
    </div>
  );
}

The <Form> component delivers:

Prefetching: It prefetches layout and loading UI when the form comes into view, speeding up navigation.
Client-side Navigation: On submission, shared layouts and client-side state are preserved.
Progressive Enhancement: Forms still work if JavaScript isn’t loaded, ensuring full-page navigation.

TurboPack: Turbocharged Development

Next.js 15 enables TurboPack during development. By running next dev --turbo, we can now experience blazing-fast local server startups and quicker code refreshes. On the Vercel app, for instance, TurboPack achieved a 75% faster local server startup and 95% faster code updates with Fast Refresh.

In my sample project we are defaulting the dev server to turbopack by adapting the development script as such:

"scripts": {
    "dev": "next dev --turbo",
}

Static Route Indicator in Dev Mode

Another helpful addition in the development experience is the static route indicator. This feature helps us quickly identify which routes are static during the development process, providing useful insights into our application's structure.

ESLint 9 Support

Next.js 15 introduces support for ESLint 9, while remaining backwards-compatible with ESLint 8. Along with this, the update to eslint-plugin-react-hooks v5 ensures even better support for React hook usage, further improving code quality in our Next.js projects.

TypeScript in next.config.ts

For TypeScript enthusiasts (like myself), the next.config.js file now supports TypeScript, allowing developers to create next.config.ts files and benefit from TypeScript’s type checking.

Stable Instrumentation and the onRequestError Hook

Instrumentation is now stable in Next.js 15, thanks to the introduction of the register() API. This allows us to hook into the Next.js server lifecycle for performance monitoring, error tracking, and deep integration with observability libraries like OpenTelemetry.

There’s also a collaboration with Sentry, introducing the new onRequestError hook. This hook captures critical error context, helping us catch and track server-side issues.

Starter repository for v15 with examples

dimeloper / nextjs-v15-starter

A starter project that showcases v15 features.

Next.js v15 Features Examples

This project demonstrates the usage of new React 19 hooks in a Next.js application, as well as new features introduced in Next.js 15. It includes comprehensive examples of various hooks, components, and React best practices including when and when not to use useEffect.

Getting Started

First, install the dependencies:

yarn install

Then, run the development server (turbopack):

yarn dev

Open http://localhost:3000 with your browser to see the result.

Project Structure

The project is organized as follows:

├── app/
│   ├── favicon.ico
│   ├── globals.css
│   ├── layout.tsx
│   ├── page.tsx
│   ├── components/
│   │   └── FooterLink.tsx
│   ├── form-showcase/
│   │   └── page.tsx
│   ├── search/
│   │   └── page.tsx
│   ├── useeffect-showcase/
│   │   ├── page.tsx
│   │   ├── api-fetching/
│   │   │   └── page.tsx
│   │   ├── browser-events/
│   │   │   └── page.tsx
│   │   ├── button-click-state/
│   │   │   └── page.tsx

…

View on GitHub

Wrapping Up

Next.js 15 brings us a lot of nice features that enhance both developer experience and performance. Make sure to try out these updates in your own projects to see the improvements for yourself.

Building a GenAI Fitness App with Gemini

Dimitris Kiriakakis — Fri, 27 Sep 2024 08:48:30 +0000

Last summer, when I found out about the Gemini API Developer Competition, I saw it as a great chance to get my hands dirty with GenAI applications. As fitness enthusiasts, we (me & Manos Chainakis) thought of creating an app that could generate personalised workout and nutrition plans—combining AI with the preferences of human coaches. That’s how Fitness Tribe AI was born. This post will walk you through the development process and the tech stack I used, with focus on the GenAI aspect.

Fitness Tribe AI | Gemini API Developer Competition | Google AI for Developers

Making Personal Training Better for Everyone, Everywhere.

ai.google.dev

The Concept Behind Fitness Tribe AI

Fitness Tribe AI combines the expertise of human coaches with the capabilities of AI models to create custom fitness programs that meet each athlete's needs and goals.

The Tech Stack

The main components of the tech stack are:

FastAPI for the backend and AI model integration
Supabase for user authentication and data management
Ionic & Angular for the frontend mobile app
Astro for the landing page

FastAPI: Backend and AI Integration

FastAPI serves as the backbone of Fitness Tribe AI, handling the AI-powered analysis.

Here’s how the project is structured:

fitness-tribe-ai/
├── app/
│   ├── main.py              # Entry point for FastAPI app
│   ├── routers/             # Handles API routes (meals, nutrition, workouts)
│   ├── models/              # Manages interactions with AI models
│   ├── schemas/             # Pydantic models for input validation
│   ├── services/            # Business logic for each feature

Key elements of the FastAPI implementation:

API Routing: Routes are divided into separate files for meals (meals.py), workouts (workouts.py), and nutrition (nutrition.py), keeping the API structure organised and scalable. Each router is connected in main.py, where FastAPI’s routing system ties everything together.

from fastapi import FastAPI
from app.routers import meals, nutrition, workouts

app = FastAPI()

app.include_router(meals.router)
app.include_router(nutrition.router)
app.include_router(workouts.router)

Gemini Model Integration: The GeminiModel class, in gemini_model.py, handles the AI model interaction. Taking as an example the meal analyzer method, I am using Pillow to process image data, and the app sends both the image and a custom prompt to the Gemini AI to analyze meal details. An important detail here is that the prompt should be specific enough, when it comes to the format of the expected response, so that it can be processed by the service layer.

class GeminiModel:
    @staticmethod
    def analyze_meal(image_data):
        prompt = (
            "Analyze the following meal image and provide the name of the food, "
            "total calorie count, and calories per ingredient..."
            "Respond in the following JSON format:"
            "{'food_name': '<food name>' ...}"
        )
        image = Image.open(BytesIO(image_data))
        response = model.generate_content([prompt, image])
        return response.text

Pydantic Schema for Data Validation: The response from the AI model is validated and structured using Pydantic models. For instance, the Meal schema in schemas/meal.py ensures the response is consistent before it is returned to the user.

from pydantic import BaseModel
from typing import Dict

class Meal(BaseModel):
    food_name: str
    total_calories: int
    calories_per_ingredient: Dict[str, int]

Service Layer: The service layer, located in services/, encapsulates the logic of each feature. For example, the meal_service.py handles the meal analysis, ensuring the data is properly processed before returning the AI results.

from app.models.gemini_model import GeminiModel
from app.schemas.meal import Meal
from fastapi import HTTPException
import logging
import json

def analyze_meal(image_data: bytes) -> Meal:
    try:
        result_text = GeminiModel.analyze_meal(image_data)
        if not result_text:
            raise HTTPException(status_code=500, detail="No response from Gemini API")

        clean_result_text = result_text.strip("```

json\n").strip("

```")
        result = json.loads(clean_result_text)
        return Meal(
            food_name=result.get("food_name"),
            total_calories=result.get("total_calories"),
            calories_per_ingredient=result.get("calories_per_ingredient"),
        )
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

By leveraging FastAPI’s modular structure, clear API routing, Pydantic for data validation, and well-organized service logic, Fitness Tribe AI efficiently handles AI model interactions with custom prompts to deliver personalized fitness and nutrition insights. You can find the full repo here:

fitness-tribe / fitness-tribe-ai

Fitness Tribe AI is an AI-powered API, providing endpoints for coaches and athletes.

Fitness Tribe API

Fitness Tribe AI is an AI-powered fitness API designed for coaches and athletes. The API provides meal analysis functionality by analyzing meal photos and an AI powered workout builder, which can generate workout plans based on athlete profiles. Fitness Tribe AI has been built the Gemini model.

Features

Meal Analysis: Upload a photo of a meal to receive a detailed analysis of its ingredients and calorie count.
Workout Builder: Input an athlete's profile details to receive a personalized workout plan tailored to the athlete's fitness goal.

Project Structure

fitness-tribe-ai/
├── app/
│   ├── __init__.py
│   ├── main.py
│   ├── models/
│   │   ├── __init__.py
│   │   ├── gemini_model.py
│   ├── routers/
│   │   ├── __init__.py
│   │   ├── meals.py
│   │   ├── nutrition.py
│   │   ├── workouts.py
│   ├── schemas/
│   │   ├── __init__.py
│   │   ├── meal.py
│   │   ├── nutrition.py
│   │   ├──

…

View on GitHub

Supabase: User Management & Auth

For user authentication and account management, I used Supabase, which provided a secure, scalable solution without requiring a custom-built authentication system.

Key features I leveraged:

Authentication: Supabase's built-in authentication enabled users to log in and manage their profiles with ease.
Database Management: Using Supabase’s PostgreSQL-backed database, I stored user preferences, workout routines, and meal plans to ensure updates reflected immediately in the app.

Ionic & Angular: Cross-Platform Frontend

For the frontend, I chose Ionic and Angular, which enabled me to create a mobile-first app that could be deployed on the web right away while it could also be shipped as native for both iOS and Android.

Astro: A Lightning-Fast Landing Page

For the landing page, I opted for Astro, which focuses on performance by shipping minimal JavaScript. Astro allowed me to build a fast, lightweight page that efficiently showcased the app.

Conclusion

Developing Fitness Tribe AI was a learning journey that enabled me to explore the power that AI models give us nowadays. Each framework played a role, from FastAPI’s robust backend capabilities and ease of use to Supabase’s user management, Ionic’s cross-platform frontend and Astro’s high-performance landing pages.

For anyone looking to build a GenAI app, I highly recommend exploring these frameworks (and especially FastAPI) for their powerful features and smooth developer experience.

Have questions or want to learn more about it? Let me know in the comments!

Viewport height and width units in modern CSS

Dimitris Kiriakakis — Wed, 17 Jul 2024 15:19:25 +0000

As I keep encountering CSS codebases and theme definitions that solely use the traditional viewport units vh and vw, I thought about writing a blog post about some additional viewport units we have on our disposal nowadays, that can make our lives easier and improve our CSS code.

The good old viewport units

Long story short, for many years we've been using vh and vw to define something as percentage of the initial viewport height and width. For example, if we wanted to fill the entire viewport of all devices with green, we could do the following:

.big-fat-green-element {
  background: green;
  height: 100vh;
  width: 100vw;
}

..and this would probably do the trick. But this would only work reliably until for whatever reason, something affected the visible viewport. For instance, most of the modern mobile browsers will hide part or all of the title and address bar once the user starts scrolling the page, also affecting the viewport and making our big fat green element less big.

The modern viewport units

Nowadays and in latest CSS specifications we can safely use the so called Large, Small, and Dynamic Viewport Units.

Large Viewport Units

The large viewport-percentage units (lv*) and default viewport-percentage units (v*) are defined with respect to the large viewport size: the viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be retracted.

Essentially, lvh and lvw give us units that we can use as percentage in relation to the viewport when the browser UI is the smallest and website content is at its largest state. lvh and lvw will actually give us identical behaviour to the traditional vh and vw units.

Example: An example of using the lvh and lvw units would be to define the height and width of an element that should act as full page background.

/* Full-page background using largest available viewport height and width, regardless of other elements or browser UI state. */
.full-page-background {
  height: 100lvh;
  background: #f51;
  position: fixed;
  top: 0;
  left: 0;
  width: 100lvw;
  z-index: -1; /* Ensure it stays behind other content */
}

Small Viewport Units

The small viewport-percentage units (sv*) are defined with respect to the small viewport size: the viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be expanded.

In other words, svh and svw give us units that we can use to fill the screen when the browser UI is at its largest state, and the website content is at its smallest state.

Example: A good example of using the svh unit would be to define the height of a fixed bottom bar or a static header.

/* Header with static height, 10% of the smallest available viewport 
 * e.g. when the browser UI is visible on mobile devices */
.header {
  height: 10svh;
  background-color: #642;
}

Dynamic Viewport Units

The dynamic viewport-percentage units (dv*) are defined with respect to the dynamic viewport size: the viewport sized with dynamic consideration of any UA interfaces that are dynamically expanded and retracted.

The sizes of the dynamic viewport-percentage units are not stable even while the viewport itself is unchanged. Using these units can cause content to resize e.g. while the user scrolls the page. Depending on usage, this can be disturbing to the user and/or costly in terms of performance.

While the dvh & dvw units may sound ideal, the caveats noted in the definition above and some issues I had when using them in scrolling elements, made me conclude that we should only use them in very specific situations.

Example 1: An example of using dvh would be to define the height of a content element that should adjust as per viewport changes.

/* Main content adjusts dynamically. 
 * Since we used dvh the element height will align with the actual viewport and adapt to its changes */
.adjustable-content {
  background-color: #895;
  height: calc(100dvh - 10svh); /* Adjust height considering header */
  overflow: auto;
  padding: 10px;
}

Example 2: I had this case last week when a bug was reported about a form where by design, scrolling was disabled while the form would occupy the full height and width of the viewport. The bug occurred when a mobile user would focus on an input and the device keyboard would show up. Then the form layout would break. The fix was to use dvh instead of vh for its height definition.

Codepen with Examples

Finally here is a codepen where you can see the modern viewport units in action. Enjoy!

Managing environment variables in Angular apps

Dimitris Kiriakakis — Tue, 02 Jul 2024 12:18:58 +0000

Some days ago I had to initialise a new Angular app for a side project of mine. The use case would be fairly simple, and I needed some basic features like user authentication and some entities to store on a backend.

In such cases Supabase is a great open-source alternative to setting up a custom backend, and integrating it into an Angular app is fairly simple, given the existing supabase dependencies like @supabase/supabase-js. The only prerequisite to make it work is initialising a supabase project and generating an API key.

However, I found out that managing environment variables in an Angular project is not really straight forward. Once we generate a project via the Angular CLI, we get the environment.ts and environment.prod.ts files, but these cannot be used for declaring such API keys, especially if we want to push our codebase to a github repository.

After some research I did, I discovered @ngx-env/builder which, as it seems, provides us with a clean and secure way to store our environment variables.

You can find a sample project showcasing how it works here:

dimeloper / angular-environment-variables

A sample Angular app that showcases how to set up env variables for different environments.

Angular Environment Variables

A sample Angular app that showcases how @ngx-env/builder can be used to introduce Environment Variables and different app environments within an Angular application.

Add package and adjust angular configuration

open a terminal
go to the project root folder
execute ng add @ngx-env/builder

Define Environment variables

create .env file in your local project directory
add it in your .gitignore
extend the Env interface within env.d.ts so that the new variables and their types are added below NODE_ENV (e.g. readonly NG_APP_ENV: string;)
add your environment variables and their values within your local .env file with the following format:

NG_APP_PUBLIC_SUPABASE_URL=https://test.supabase.co
NG_APP_PUBLIC_SUPABASE_ANON_KEY=keykeykeyvaluevalue

Note that all the environment variables should be prefixed with NG_.

Differentiate environments across serve and build tasks

You could possible use the default NODE_ENV values to differentiate between e.g. development and production environments, however I prefer having my own app environment values…

View on GitHub

Getting started

Once we are at our Angular project root directory we can simply run ng add @ngx-env/builder to get started. This command will install the necessary dependency, adjust the application builders accordingly and generate the environment types within env.d.ts.

Once this is complete we can extend the generated env.d.ts and its Env interface with our expected environment variables. For example:

declare interface Env {
  readonly NODE_ENV: string;
  // Replace the following with your own environment variables.
  readonly NG_APP_ENV: string;
  readonly NG_APP_PUBLIC_SUPABASE_URL: string;
  readonly NG_APP_PUBLIC_SUPABASE_ANON_KEY: string;
}

Please keep in mind that the NG_APP_ prefix is mandatory. In case you need to change it please consult the related documentation.

Defining Environment Variables

Now we can use .env files on our local and production environments with the corresponding values. First we need to make sure that our .gitignore includes the .env file. Then we can create our local .env file as such:

NG_APP_PUBLIC_SUPABASE_URL=https://test.supabase.co
NG_APP_PUBLIC_SUPABASE_ANON_KEY=keykeykeyvaluevalue

Since we included this file as part of our .gitignore, these values won't be pushed to our github repository.

Usage in components / templates

We can import the actual values of our environment variables in our components as such:

supabaseUrl = import.meta.env.NG_APP_PUBLIC_SUPABASE_URL;

Basically the import.meta.env object will include all the environment variables we've defined.

Differentiate environments across serve and build tasks

We could possibly use the default NODE_ENV values to differentiate between e.g. development and production environments, however I prefer having my own app environment values which for this sample project, I've defined within package.json.

Example:

"scripts": {
  "start:dev": "NG_APP_ENV=dev ng serve",
  "start:staging": "NG_APP_ENV=staging ng serve",
  "start:production": "NG_APP_ENV=production ng serve",
  "build": "NG_APP_ENV=production ng build"
}

By doing this we have a clear app environment separation, while we are also able to differentiate pieces of implementation depending on the app environment, e.g. if we want to show a teaser component only on production or staging.

Deployment / usage in production

Once our local setup is complete, we can overwrite the values of our environment variables, just by defining them on the staging/production system environment (e.g. export NG_APP_PUBLIC_SUPABASE_URL="environment.specific.url"), or by creating an .env file in there, including all the enviroment specific values (e.g. staging values on the testsystem, production values on the live server).

Conclusion

Managing API keys and secret values that should be handled as environment variables is an essential part of any frontend application that should be production ready. The @ngx-env/builder package provides us with an elegant and straightforward way to do so, when it comes to Angular apps. Enjoy!

Forem: Dimitris Kiriakakis

Event-Driven State Management with NgRx Signal Store

The Problem with Direct Method Calls

Why Event-Driven Architecture?

Understanding Flux Architecture

How the Events Plugin Implements Flux

Setting Up the Events Plugin

Defining Task Events

Understanding the Event Structure

Implementing Reducers

The Reducer Pattern

Understanding Reducer Mechanics

The Power of Declarative Updates

Implementing Effects

The Effect Pattern

Understanding Effect Mechanics

Creating Reusable Features

Composing the Store

Configuration Setup

Dispatching Events from Components

Testing Event-Driven Flows

Testing Philosophy

Testing Reducers

Testing Effects

Integration Testing

Why This Approach Works

When to Use Event-Driven Architecture

Resources

Choosing Tech Stack in 2025: A Practical Guide

Table of Contents

Frontend Stacks

React Ecosystem

Angular

Vue

Backend Stacks

Node.js/TypeScript

GoLang

Python

Full Stack Solutions

The T3 Stack: Type-Safety First

FastAPI + Angular/Next + Flutter: All platforms included

Decision Framework

Learning and Side Projects

Startups and MVPs

Enterprise Applications

Conclusion

Mastering AI-Assisted Software Development: From Prompts to Production-Ready Code

Set the Ground Rules: Copilot Instruction Files and Chat Modes

Instruction Files for Consistency Across Your Codebase

Defining Task-Specific AI Behavior with Custom Chat Modes

Structure of a Custom Chat Mode

1. Frontmatter metadata (YAML)

2. Body instructions

Establish a Pattern: Show AI What “Good” Looks Like

Integrate Testing Early: Use AI to Validate Behavior

Document as You Go: Let AI Capture What Just Happened

Final Thoughts

Using NgRx Signal Store for State Management in Angular

Why Signal Store

Signal Store structure

Store and service separation still makes sense

Real-time logging for store actions

Testing the store with Vitest

Final thoughts

CSS techniques every developer should know in 2025

Container Queries

Cascade Layers

The @property Rule

Animation Composition

Text-wrap: balance

Final thoughts

Building Accessible Web Applications: A Practical Guide for EAA Compliance

Who needs to comply with the EAA?

Legal consequences of non-compliance

Common accessibility mistakes (and how to fix them)

Must-Haves: Essentials for accessibility compliance

1. Ensuring the page head is accessible

2. Using aria-labelledby for section headings

3. Adding proper labels and ARIA attributes to forms

4. Important state changes announcements

From `git checkout` to `git switch` and `git restore`

Managing Changes: `git stash` → `git worktree`

Why use `git worktree`:

Undoing Changes: `git reset` → `git restore`

Why use `git restore`:

Simplify Status Checks: `git status` → `git status -sb`

Why use `git status -sb`:

Cleaner Pulls: `git pull` → `git pull --rebase`

Why use `git pull --rebase`:

Save the trouble of typing `--rebase` every time:

Introducing the New `<Form>` Component