DEV Community: nsimonoski

Testing the 7 Signal Store Features

nsimonoski — Mon, 13 Apr 2026 11:21:02 +0000

Every store that uses withLoading() doesn't need to re-test that setLoading(true) sets isLoading to true. That's the feature's job. Test the feature once, and every store that composes it gets that behavior for free.

These features were not built with TDD. They went through multiple API changes before settling - writing tests during that phase means rewriting them every time the API shifts. Once the APIs stabilized, it was time to write tests. Time better spent on the feature itself.

These tests don't verify framework behavior. Angular's template binding, change detection, signal reactivity - that's already tested by the Angular team. If a signal value changes in the store, the template updates. That's Angular's contract, not ours. Tests here cover the store logic only: if setLoading(true) was called, the component is guaranteed to reflect it - that's already tested in the feature store.

This post shows how to test each of the 7 features from the previous post and what consuming store tests look like after that.

The Setup: A Minimal Test Store

Features can't run on their own - they need a host store. Every test creates a minimal one:

const TestStore = signalStore(
  { providedIn: 'root' },
  withState({ name: 'test' }),
  withLoading(),
);

function setup() {
  return TestBed.inject(TestStore);
}

No component, no template.

Testing withLoading

Pure state - no dependencies to mock.

describe('withLoading', () => {
  const TestStore = signalStore(
    { providedIn: 'root' },
    withState({ name: 'test' }),
    withLoading(),
  );

  function setup() {
    return TestBed.inject(TestStore);
  }

  it('should initialize with loading false and no error', () => {
    const store = setup();
    expect(store.isLoading()).toBe(false);
    expect(store.errorMessage()).toBe('');
  });

  it('should set loading to true by default when called without args', () => {
    const store = setup();
    store.setLoading();
    expect(store.isLoading()).toBe(true);
  });

  it('should set error message', () => {
    const store = setup();
    store.setLoading(false, 'Something went wrong');
    expect(store.errorMessage()).toBe('Something went wrong');
  });
});

Testing withBrowserStorage

Tests interact with real localStorage - no need to mock the Web Storage API.

describe('withBrowserStorage', () => {
  const STORAGE_KEY = 'test-store';

  const TestStore = signalStore(
    { providedIn: 'root' },
    withState({ count: 0, label: 'default' }),
    withBrowserStorage({ key: STORAGE_KEY }),
  );

  function setup() {
    localStorage.clear();
    sessionStorage.clear();
    return TestBed.inject(TestStore);
  }

  it('should return false when no saved data exists', () => {
    const store = setup();
    expect(store.loadFromStorage()).toBe(false);
  });

  it('should load saved data and patch state', () => {
    const store = setup();
    localStorage.setItem(STORAGE_KEY, JSON.stringify({ count: 42 }));
    expect(store.loadFromStorage()).toBe(true);
    expect(store.count()).toBe(42);
  });

  it('should not overwrite fields that were not saved', () => {
    const store = setup();
    localStorage.setItem(STORAGE_KEY, JSON.stringify({ count: 10 }));
    store.loadFromStorage();
    expect(store.count()).toBe(10);
    expect(store.label()).toBe('default');
  });

  it('should save data to localStorage and patch state', () => {
    const store = setup();
    store.saveToStorage({ count: 99 });
    expect(store.count()).toBe(99);
    expect(JSON.parse(localStorage.getItem(STORAGE_KEY)!)).toEqual({ count: 99 });
  });

  it('should merge with existing saved data', () => {
    const store = setup();
    localStorage.setItem(STORAGE_KEY, JSON.stringify({ count: 1 }));
    store.saveToStorage({ label: 'updated' });
    const saved = JSON.parse(localStorage.getItem(STORAGE_KEY)!);
    expect(saved).toEqual({ count: 1, label: 'updated' });
  });

  it('should preserve specified keys on clearAll', () => {
    const store = setup();
    localStorage.setItem('keep-me', '"value"');
    localStorage.setItem('remove-me', '"gone"');
    store.clearAllStorage(['keep-me']);
    expect(localStorage.getItem('keep-me')).toBe('"value"');
    expect(localStorage.getItem('remove-me')).toBeNull();
  });
});

Testing withSnackbar

Injects SnackbarService - one mock via TestBed:

describe('withSnackbar', () => {
  const TestStore = signalStore(
    { providedIn: 'root' },
    withState({ name: 'test' }),
    withSnackbar(),
  );

  function setup() {
    TestBed.configureTestingModule({
      providers: [{ provide: SnackbarService, useValue: mockSnackbarService() }],
    });
    return TestBed.inject(TestStore);
  }

  it('should show success snackbar', () => {
    const store = setup();
    store.showSuccess('Saved!');
    expect(TestBed.inject(SnackbarService).success).toHaveBeenCalledWith('Saved!', undefined);
  });

  it('should show error snackbar', () => {
    const store = setup();
    store.showError('Failed!');
    expect(TestBed.inject(SnackbarService).error).toHaveBeenCalledWith('Failed!', undefined);
  });

  it('should dismiss snackbar', () => {
    const store = setup();
    store.dismissSnackbar();
    expect(TestBed.inject(SnackbarService).dismiss).toHaveBeenCalled();
  });
});

Testing withDialog

Pure state. The callback is closure-scoped - tested by the consuming store, not here.

describe('withDialog', () => {
  const TestStore = signalStore(
    { providedIn: 'root' },
    withState({ name: 'test' }),
    withDialog(),
  );

  function setup() {
    return TestBed.inject(TestStore);
  }

  it('should initialize with dialog closed', () => {
    const store = setup();
    expect(store.dialogOpen()).toBe(false);
    expect(store.dialogTitle()).toBe('');
    expect(store.dialogMessage()).toBe('');
  });

  it('should open dialog with title, message, and data', () => {
    const store = setup();
    store.openDialog('Delete File', 'Are you sure?', { filePath: '/src/main.ts' });
    expect(store.dialogOpen()).toBe(true);
    expect(store.dialogTitle()).toBe('Delete File');
    expect(store.dialogData()).toEqual({ filePath: '/src/main.ts' });
  });

  it('should close dialog and reset all fields', () => {
    const store = setup();
    store.openDialog('Title', 'Message', { id: 1 });
    store.closeDialog();
    expect(store.dialogOpen()).toBe(false);
    expect(store.dialogTitle()).toBe('');
    expect(store.dialogData()).toBeNull();
  });
});

Testing withRouting

Router and ActivatedRoute mocks are needed here. Every store that composes withRouting() skips them - mock factories handle it.

describe('withRouting', () => {
  const routerEvents$ = new Subject<NavigationEnd>();

  const mockRouter = {
    url: '/initial',
    events: routerEvents$.asObservable(),
    navigateByUrl: vi.fn(),
    createUrlTree: vi.fn().mockReturnValue({}),
    serializeUrl: vi.fn().mockReturnValue('/serialized'),
  };

  const mockActivatedRoute = {
    snapshot: {
      params: { id: '123' },
      queryParams: { tab: 'files' },
      data: { title: 'Test' },
    },
  };

  const TestStore = signalStore(
    { providedIn: 'root' },
    withState({ name: 'test' }),
    withRouting(),
  );

  function setup() {
    TestBed.configureTestingModule({
      providers: [
        { provide: Router, useValue: mockRouter },
        { provide: ActivatedRoute, useValue: mockActivatedRoute },
      ],
    });
    return TestBed.inject(TestStore);
  }

  it('should expose current URL signal with initial value', () => {
    const store = setup();
    expect(store.currentUrl()).toBe('/initial');
  });

  it('should navigate to a route', () => {
    const store = setup();
    store.navigate('/editor');
    expect(mockRouter.navigateByUrl).toHaveBeenCalledWith('/editor');
  });

  it('should return route params and query params', () => {
    const store = setup();
    expect(store.getRouteParams()).toEqual({ id: '123' });
    expect(store.getQueryParams()).toEqual({ tab: 'files' });
  });

  it('should open a new tab with serialized URL', () => {
    const store = setup();
    const openSpy = vi.spyOn(window, 'open').mockImplementation(() => null);
    store.openInNewTab('/preview', { mode: 'dark' });
    expect(mockRouter.createUrlTree).toHaveBeenCalledWith(['/preview'], {
      queryParams: { mode: 'dark' },
    });
    expect(openSpy).toHaveBeenCalledWith('/serialized', '_blank');
    openSpy.mockRestore();
  });
});

Testing withGitActions (Domain Feature)

withGitActions uses withSnackbar internally, so the test provides SnackbarService.

describe('withGitActions', () => {
  const TestStore = signalStore(
    { providedIn: 'root' },
    withState({ name: 'test' }),
    withGitActions(),
  );

  function setup() {
    const git = mockGitService();
    const snackbar = mockSnackbarService();
    TestBed.configureTestingModule({
      providers: [
        { provide: GitService, useValue: git },
        { provide: SnackbarService, useValue: snackbar },
        { provide: GitStatusStore, useValue: mockGitStatusStore() },
      ],
    });
    return { store: TestBed.inject(TestStore), git, snackbar };
  }

  it('should call commit and show success', () => {
    const { store, git, snackbar } = setup();
    store.gitCommit('feat: add feature');
    expect(git.commit).toHaveBeenCalledWith('/workspace/repo', 'feat: add feature');
    expect(snackbar.success).toHaveBeenCalledWith('Committed!', undefined);
  });

  it('should show error on failure', () => {
    const { store, git, snackbar } = setup();
    git.commit.mockReturnValue(of({ success: false, error: 'Commit failed' }));
    store.gitCommit('bad commit');
    expect(snackbar.error).toHaveBeenCalledWith('Commit failed', undefined);
  });

  it('should stage files', () => {
    const { store, git } = setup();
    store.gitStage(['src/main.ts', 'src/app.ts']);
    expect(git.stage).toHaveBeenCalledWith('/workspace/repo', ['src/main.ts', 'src/app.ts']);
  });
});

What Consuming Store Tests Look Like

IdeLayoutStore uses withBrowserStorage and withRouting. Mock factories handle those dependencies:

describe('IdeLayoutStore', () => {
  function setup() {
    localStorage.clear();
    TestBed.configureTestingModule({
      providers: [
        { provide: Router, useValue: mockRouter() },
        { provide: ActivatedRoute, useValue: mockActivatedRoute() },
        { provide: CodeEditorStore, useValue: mockCodeEditorStore() },
      ],
    });
    return TestBed.inject(IdeLayoutStore);
  }

  it('should toggle terminal and persist', () => {
    const store = setup();
    store.toggleTerminal();
    expect(store.terminalOpen()).toBe(true);
    const saved = JSON.parse(localStorage.getItem('ide-layout')!);
    expect(saved.terminalOpen).toBe(true);
  });

  it('should clamp terminal height between 100 and 600', () => {
    const store = setup();
    store.setTerminalHeight(50);
    expect(store.terminalHeight()).toBe(100);
    store.setTerminalHeight(800);
    expect(store.terminalHeight()).toBe(600);
  });
});

Same with AiChatStore:

describe('AiChatStore', () => {
  function setup() {
    localStorage.clear();
    const ai = mockAiService();
    TestBed.configureTestingModule({
      providers: [
        { provide: AiService, useValue: ai },
        { provide: SnackbarService, useValue: mockSnackbarService() },
        { provide: CodeEditorStore, useValue: mockCodeEditorStore() },
      ],
    });
    return { store: TestBed.inject(AiChatStore), ai };
  }

  it('should send message and create user + assistant entries', () => {
    const { store, ai } = setup();
    ai.sendMessage.mockReturnValue(of({ delta: 'Hello!', done: true }));
    store.sendMessage({ userMessage: 'Hi' });
    expect(store.messages().length).toBe(2);
    expect(store.messages()[0].role).toBe('user');
    expect(store.messages()[1].role).toBe('assistant');
    expect(store.messages()[1].content).toBe('Hello!');
  });

  it('should compute questionCount', () => {
    const { store } = setup();
    expect(store.questionCount()).toBe(0);
  });
});

What Makes This Work

No async or fakeAsync. Signal stores are synchronous. rxMethod with mockReturnValue(of(...)) completes inline.

Mock factories live in a shared testing lib. mockGitService(), mockSnackbarService(), mockRouter() - defined once, used everywhere.

// @org/angular-testing
export function mockSnackbarService() {
  return {
    success: vi.fn(),
    error: vi.fn(),
    info: vi.fn(),
    dismiss: vi.fn(),
  };
}

The Bigger Picture

When withBrowserStorage changes internally, one test file updates. The stores that use it don't change.

Same applies to components. Stores own all the logic - HTTP calls, state, routing, dialogs. Components inject a store, read signals, call methods. They don't know if the data comes from a REST API, a WebSocket, or localStorage. Testing a component means mocking the store and checking the template. No HttpClientTestingModule, no RouterTestingModule.

The code in this post comes from the same portfolio project as the previous posts. If you want to see how these features fit into a larger monorepo, check out the architecture post. The features themselves are covered in 7 Signal Store Features You Only Need to Write Once.

7 Signal Store Features You Only Need to Write Once

nsimonoski — Thu, 09 Apr 2026 16:32:31 +0000

The Repetition Problem

Every Angular store ends up doing the same things. A loading flag. An error message. Persistence to localStorage. A snackbar for success feedback. Reading query params from the router. Opening a dialog.

Without composition, this logic gets copied between stores - or leaks into components where it doesn't belong. Every store ends up with its own slightly different way of tracking "is this thing loading right now."

ngrx signal store solves this with signalStoreFeature. Beyond reducing duplication, these features decouple components from implementation details. When a UI library changes, an Angular API evolves, or you swap out a dependency - you update the feature once and every store that uses it stays untouched.

Quick Recap: What is signalStoreFeature?

signalStoreFeature lets you extract reusable store logic - state, computed signals, methods, hooks - into composable units:

export const MyStore = signalStore(
  { providedIn: 'root' },
  withState({ count: 0 }),
  withLoading(),
  withBrowserStorage({ key: 'my-store' }),
);

TypeScript merges the types from all features, so autocompletion works across everything. For a deeper dive, check the official NgRx docs.

Feature 1: withLoading

Every store needs loading state and error tracking. Instead of redefining it everywhere:

import { patchState, signalStoreFeature, withMethods, withState } from '@ngrx/signals';

export const withLoading = () =>
  signalStoreFeature(
    withState<{ isLoading: boolean; errorMessage: string }>({
      isLoading: false,
      errorMessage: '',
    }),
    withMethods((state) => ({
      setLoading(isLoading = true, errorMessage?: string): void {
        patchState(state, { isLoading, errorMessage });
      },
    })),
  );

Components read userStore.isLoading() and userStore.errorMessage() as signals. One consistent API across every store. No more guessing whether it's loading$ or isLoading$ or isLoading.

Feature 2: withBrowserStorage

Wraps localStorage or sessionStorage with a configurable key:

import { patchState, signalStoreFeature, withMethods } from '@ngrx/signals';

interface BrowserStorageConfig {
  key: string;
  type?: 'local' | 'session';
}

function browserStorage<T>(key: string, options?: { type?: 'local' | 'session' }) {
  const storage = options?.type === 'session' ? sessionStorage : localStorage;

  return {
    load(): T | null {
      try {
        const raw = storage.getItem(key);
        return raw ? JSON.parse(raw) : null;
      } catch {
        return null;
      }
    },
    save(data: Partial<T>): void {
      const existing = this.load();
      storage.setItem(key, JSON.stringify({ ...existing, ...data }));
    },
    clearAll(preserveKeys: string[] = []): void {
      const preserved = preserveKeys.map((k) => [k, localStorage.getItem(k)] as const);
      localStorage.clear();
      sessionStorage.clear();
      preserved.forEach(([k, value]) => value && localStorage.setItem(k, value));
    },
  };
}

export const withBrowserStorage = (config: BrowserStorageConfig) => {
  const storage = browserStorage<Record<string, unknown>>(config.key, { type: config.type });

  return signalStoreFeature(
    withMethods((store) => ({
      loadFromStorage(): boolean {
        const saved = storage.load();
        if (!saved) return false;

        try {
          patchState(store, saved);
          return true;
        } catch {
          return false;
        }
      },
      saveToStorage(data: Record<string, unknown>): void {
        patchState(store, data);
        storage.save(data);
      },
      removeFromStorage(): void {
        storage.remove();
      },
      clearAllStorage(preserveKeys: string[] = []): void {
        storage.clearAll(preserveKeys);
      },
    })),
  );
};

The feature is a factory - it takes config and returns a signalStoreFeature(...) call. The browserStorage helper wraps localStorage/sessionStorage with JSON serialization and merge-on-save semantics. The storage instance is closed over, so every store gets its own isolated storage. patchState(store, saved) hydrates the store from the persisted data on load.

Feature 3: withSnackbar

Every store that does async work needs to show feedback. Instead of injecting a snackbar service in every store, wrap it in a feature:

import { inject } from '@angular/core';
import { signalStoreFeature, withMethods, withProps } from '@ngrx/signals';
import { SnackbarService } from '@org/angular/ui';

export const withSnackbar = () =>
  signalStoreFeature(
    withProps(() => ({
      _snackbar: inject(SnackbarService),
    })),
    withMethods((store) => ({
      showSuccess(message?: string, duration?: number): void {
        store._snackbar.success(message, duration);
      },
      showError(message?: string, duration?: number): void {
        store._snackbar.error(message, duration);
      },
      showInfo(message?: string, duration?: number): void {
        store._snackbar.info(message, duration);
      },
      dismissSnackbar(): void {
        store._snackbar.dismiss();
      },
    })),
  );

If you later switch to Angular Material's MatSnackBar or any other UI library, you update withSnackbar once. Every consumer keeps calling showSuccess().

Feature 4: withDialog

Confirmation dialogs need state for visibility, a message, and a way to carry context about what is being confirmed. The confirm action is different every time - delete a file, remove a user, discard changes. Without a callback, the component needs branching logic.

import { patchState, signalStoreFeature, withMethods, withState } from '@ngrx/signals';

interface DialogState {
  dialogOpen: boolean;
  dialogTitle: string;
  dialogMessage: string;
}

export const withDialog = () => {
  let onConfirm: (() => void) | null = null;

  return signalStoreFeature(
    withState<DialogState>({
      dialogOpen: false,
      dialogTitle: '',
      dialogMessage: '',
    }),
    withMethods((state) => ({
      openDialog(title: string, message: string, cb: () => void): void {
        onConfirm = cb;
        patchState(state, { dialogOpen: true, dialogTitle: title, dialogMessage: message });
      },
      confirmDialog(): void {
        onConfirm?.();
        onConfirm = null;
        patchState(state, { dialogOpen: false, dialogTitle: '', dialogMessage: '' });
      },
      closeDialog(): void {
        onConfirm = null;
        patchState(state, { dialogOpen: false, dialogTitle: '', dialogMessage: '' });
      },
    })),
  );
};

The callback is closure-scoped, not serializable state:

@Component({
  template: `
    <ui-confirmation-dialog
      [isOpen]="store.dialogOpen()"
      [title]="store.dialogTitle()"
      [message]="store.dialogMessage()"
      (confirmed)="store.confirmDialog()"
      (cancelled)="store.closeDialog()"
    />
  `,
})
export class FileExplorerComponent {
  readonly store = inject(FileExplorerStore);

  handleDelete(node: FileNode): void {
    store.openDialog('Delete', `Delete "${node.name}"?`, () => store.delete(node.path));
  }

  handleRename(node: FileNode): void {
    store.openDialog('Rename', `Rename "${node.name}"?`, () => store.rename(node));
  }
}

Feature 5: withRouting

Features can inject Angular services. withProps runs inside the store's injection context, so inject(Router) works:

import { signalStoreFeature, withMethods, withProps } from '@ngrx/signals';
import { ActivatedRoute, Data, NavigationEnd, Params, Router } from '@angular/router';
import { inject } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';
import { filter, map } from 'rxjs';

export const withRouting = () =>
  signalStoreFeature(
    withProps(() => {
      const router = inject(Router);
      const activatedRoute = inject(ActivatedRoute);

      const navigationEnd$ = router.events.pipe(
        filter((event) => event instanceof NavigationEnd),
      );

      const currentUrl = toSignal(
        navigationEnd$.pipe(map((event) => event.urlAfterRedirects)),
        { initialValue: router.url },
      );

      const queryParams = toSignal(
        navigationEnd$.pipe(map(() => activatedRoute.snapshot.queryParams)),
        { initialValue: activatedRoute.snapshot.queryParams },
      );

      return { router, activatedRoute, navigationEnd$, currentUrl, queryParams };
    }),
    withMethods(({ router, activatedRoute }) => ({
      navigate(route: string): void {
        router.navigateByUrl(route);
      },
      openInNewTab(route: string, queryParams?: Record<string, unknown>): void {
        const urlTree = router.createUrlTree([route], { queryParams });
        const url = router.serializeUrl(urlTree);
        window.open(url, '_blank');
      },
      getRouteParams(): Params {
        return activatedRoute.snapshot.params;
      },
      getQueryParams(): Params {
        return activatedRoute.snapshot.queryParams;
      },
      getRouteData(): Data {
        return activatedRoute.snapshot.data;
      },
    })),
  );

Bonus: A Route Tree Object

Pairs well with withRouting — all route paths in one place:

const ADMIN = '/admin';
const USERS = `${ADMIN}/users`;
const PRODUCTS = '/products';

export const AppRoutes = {
  auth: {
    login: '/login',
    logout: '/logout',
    forgotPassword: '/forgot-password',
    resetPassword: (token: string) => `/reset-password?token=${token}`,
  },
  dashboard: '/dashboard',
  admin: {
    root: ADMIN,
    settings: `${ADMIN}/settings`,
    users: {
      list: USERS,
      detail: (id: string) => `${USERS}/${id}`,
      edit: (id: string) => `${USERS}/${id}/edit`,
      invite: `${USERS}/invite`,
    },
  },
  products: {
    list: PRODUCTS,
    detail: (slug: string) => `${PRODUCTS}/${slug}`,
    category: (category: string) => `${PRODUCTS}?category=${encodeURIComponent(category)}`,
    search: (query: string) => `${PRODUCTS}?q=${encodeURIComponent(query)}`,
  },
  account: {
    profile: '/account/profile',
    billing: '/account/billing',
  },
} as const;

store.navigate(AppRoutes.products.detail(product.slug));
store.navigate(AppRoutes.admin.users.edit(userId));

if (url.startsWith(AppRoutes.admin.root)) return 'admin';

Feature 6: withGitActions - Domain Feature Composition

signalStoreFeature isn't just for infrastructure. It works for domain logic too. This feature bundles every git operation in the app:

import { inject } from '@angular/core';
import { signalStoreFeature, withMethods, withProps } from '@ngrx/signals';
import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { pipe, switchMap, tap } from 'rxjs';
import { uiStore } from '@org/angular/ui';
import { GitService } from '../git.service';
import { GitStatusStore } from '../ide-store';

export const withGitActions = () =>
  signalStoreFeature(
    uiStore.withSnackbar(),
    withProps(() => ({
      _gitService: inject(GitService),
      _gitStatusStore: inject(GitStatusStore),
    })),
    withMethods((store) => ({
      gitCommit: rxMethod<string>(
        pipe(
          switchMap((message: string) =>
            store._gitService.commit(store._gitStatusStore.rootPath(), message),
          ),
          tap(({ success, error }) => {
            if (!success) return store.showError(error);
            store.showSuccess('Committed!');
          }),
        ),
      ),
      gitPush: rxMethod<void>(
        pipe(
          switchMap(() => store._gitService.push(store._gitStatusStore.rootPath())),
          tap(({ success, error }) => {
            if (!success) return store.showError(error);
            store.showSuccess('Pushed!');
          }),
        ),
      ),
      gitStage: rxMethod<string[]>(
        pipe(
          switchMap((paths: string[]) =>
            store._gitService.stage(store._gitStatusStore.rootPath(), paths),
          ),
        ),
      ),
      // ... gitUnstage, gitDiscard, gitStash, gitStashPop, gitStashApply
    })),
  );

Notice how withGitActions composes withSnackbar internally - the consuming store gets showSuccess() and showError() for free without knowing about SnackbarService. Private props use underscore prefixes (_gitService, _gitStatusStore) to signal "internal to this feature."

Feature 7: WebSocket Store

Real-time features need WebSocket connections - file watchers, git status updates, terminal sessions. A signal store wrapping socket.io gives you connection state as a signal and automatic event re-subscription on reconnect:

import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { io, Socket } from 'socket.io-client';
import { Observable } from 'rxjs';

export const WebSocketStore = signalStore(
  { providedIn: 'root' },
  withState<{ connected: boolean }>({ connected: false }),
  withMethods((store) => {
    const socket: Socket = io(WS_BASE_URL);
    const watchEvents: { event: string; data: unknown }[] = [];

    socket.on('connect', () => {
      patchState(store, { connected: true });
      for (const { event, data } of watchEvents) {
        socket.emit(event, data);
      }
    });
    socket.on('disconnect', () => patchState(store, { connected: false }));

    return {
      on<T>(event: string): Observable<T> {
        return new Observable<T>((subscriber) => {
          const handler = (data: T) => subscriber.next(data);
          socket.on(event, handler as (...args: unknown[]) => void);
          return () => socket.off(event, handler as (...args: unknown[]) => void);
        });
      },
      emit(event: string, data?: unknown): void {
        if (socket.connected) {
          socket.emit(event, data);
        }
      },
      watch(event: string, data?: unknown): void {
        const idx = watchEvents.findIndex((e) => e.event === event);
        if (idx !== -1) watchEvents.splice(idx, 1);
        watchEvents.push({ event, data });
        if (socket.connected) socket.emit(event, data);
      },
      reconnect(): void {
        socket.disconnect();
        socket.connect();
      },
      disconnect(): void {
        watchEvents.length = 0;
        socket.disconnect();
      },
    };
  }),
);

watch registers an event that gets re-emitted on every reconnect. When the server restarts or the connection drops, the client automatically re-subscribes to file watchers, git watchers, etc.

export const GitStatusStore = signalStore(
  { providedIn: 'root' },
  withState({ branch: '', changesCount: 0 }),
  withProps(() => ({
    ws: inject(WebSocketStore),
  })),
  withMethods((store) => ({
    listenToGitChanges: rxMethod<void>(
      pipe(
        switchMap(() => store.ws.on<GitStatusResponse>(GIT_CHANGE_EVENT)),
        tap(({ branch, changesCount }) => patchState(store, { branch, changesCount })),
      ),
    ),
  })),
  withHooks({
    onInit(store) {
      store.ws.watch(GIT_WATCH_EVENT, rootPath);
      store.listenToGitChanges();
    },
  }),
);

Composing Multiple Features

export const EditorPreferencesStore = signalStore(
  { providedIn: 'root' },
  withState({
    theme: 'dark' as 'dark' | 'light',
    fontSize: 14,
    wordWrap: true,
  }),
  withLoading(),
  withBrowserStorage({ key: 'editor-prefs' }),
  withSnackbar(),
  withMethods((store) => ({
    updateTheme(theme: 'dark' | 'light'): void {
      store.saveToStorage({ theme });
      store.showSuccess('Theme updated');
    },
  })),
);

Patterns to Keep in Mind

Service injection works because stores run in an injection context. inject(Router) works inside withProps and withMethods. Features can't be called outside of store definitions.

Parameterized features are factories. withBrowserStorage({ key: '...' }) returns a signalStoreFeature(...) call. Config values are closed over.

Underscore prefix = internal. _gitService, _gitStatusStore signal "don't use from outside this feature."

Never use .subscribe() inside a feature. Use rxMethod with tapResponse or tap for async work. The store handles cleanup.

Order matters. withState must come before features that read its state. TypeScript will tell you when you get this wrong.

Conclusion

These 7 features replaced duplicated code across every store in the app. New cross-cutting concerns become a feature instead of copy-pasted logic.

The pattern works for domain logic too - withGitActions groups 8 related methods into one composable unit. Stores stay thin: some state, some features, a few custom methods.

There's a testing benefit too. Each feature is a self-contained unit with minimal dependencies - test it once, and every store that composes it gets that behavior for free. Consuming stores don't need to mock Router, localStorage, or SnackbarService - that's already covered by the feature's own tests. Store tests focus on domain logic only. More on testing these features in an upcoming post.

The code in this post comes from a portfolio project I use to experiment with patterns and ship features quickly (source on GitHub). These features make it easy to spin up new stores without re-solving the same problems. If you want to see how it fits into a larger monorepo with shared contracts and multiple frontends, I wrote about that in this post.

How a Monorepo (Nx) Keeps Angular, React, and NestJS in Sync - From Shared Code to Atomic Deployments

nsimonoski — Wed, 01 Apr 2026 08:53:12 +0000

Copy-Paste Development

Every company that runs more than one project eventually faces the same problem.

It starts small. Project B needs the same user authentication logic as Project A, so someone copies the auth module over. A few months later, Project C launches and borrows the same code - plus some API utilities from Project B. By the time Project D kicks off, there are four slightly different implementations of the same auth flow, three versions of the same API types, and no one remembers which project has the "correct" version.

Each project drifts. Different ESLint configs. Different TypeScript strictness levels. Different folder structures. A junior developer joins Project C and learns patterns that don't exist in Project A. A bug gets fixed in one project's copy of a utility but never propagated to the others.

The usual answer to this is internal npm packages. Extract the shared code, publish it to a private registry, and have each project depend on it. This helps, but it introduces its own problems: now every change to shared code requires a version bump, a publish step, and a dependency update in every consuming project. Hotfixes become multi-step release processes. And if the shared package has its own dependencies, you're now managing a dependency tree across multiple registries.

The shared code problem doesn't go away - it just moves from copy-pasted files to versioned packages that still need coordination.

A monorepo takes a different approach. Instead of distributing shared code through a registry, it keeps everything in one repository with one source of truth for shared logic, one set of standards, and a build system that understands how projects relate to each other. Whether the projects use the same framework or different ones, the benefits are identical.

What a Multi-Project Monorepo Looks Like

The structure separates shared code from project-specific code:

apps/
  customer-portal/     → Project A
  admin-dashboard/     → Project B
  api/                 → Backend API

libs/
  shared/              → Used by everything
    contracts/         → TypeScript interfaces, DTOs, enums
    utils/             → Pure utility functions
    styles/            → SCSS variables, mixins, themes

  customer-portal/     → Project A specific libraries
    features/          → Feature modules
    shared/            → UI components, stores

  admin-dashboard/     → Project B specific libraries
    features/          → Feature modules
    shared/            → UI components, stores

Every project has its own space. Shared code lives in one place. The boundary between "mine" and "ours" is explicit in the folder structure.

In a real production codebase - a browser-based IDE (kod3.dev, Github Source Code) with multiple frontends and a NestJS backend - this breaks down to:

Layer	Lines of Code	% of Total
Shared (contracts, utils, terminal, styles)	~4,850	20%
Frontend A (Angular)	~8,030	33%
Frontend B (React)	~3,800	16%
Backend API (NestJS)	~3,200	13%
Application shells	~1,470	6%

That 20% of shared code is consumed by every project in the repo. Without the monorepo, those ~4,850 lines would need to exist independently in each project - copied, maintained separately, and slowly diverging. That's roughly 10,000 lines of duplication avoided.

Benefit 1: Shared Contracts - Define Once, Use Everywhere

The highest-leverage shared code is contracts: the TypeScript interfaces that define how data flows between services and projects.

Consider a git status interface used across the entire stack:

// libs/shared/contracts/src/lib/git.contract.ts

export interface GitStatusDto {
  branch: string;
  tracking: boolean;
  ahead: number;
  behind: number;
  staged: GitFileChange[];
  unstaged: GitFileChange[];
  untracked: string[];
}

export interface GitCommitRequestDto {
  message: string;
}

export const GIT_CHANGE_EVENT = 'git:change';

This single file is the source of truth for what git status data looks like. The backend returns it:

// Backend API

import type { GitStatusDto } from '@org/shared/contracts';

@Controller('git')
export class GitController {
  @Get('status')
  async status(@Query('path') path: string): Promise<GitStatusDto> {
    return this.service.status(path);
  }
}

Project A consumes it:

// Project A (Angular)

import { GitStatusDto } from '@org/shared/contracts';

@Injectable({ providedIn: 'root' })
export class GitService {
  getStatus(path: string): Observable<ApiResult<GitStatusDto>> {
    return this.http
      .get<GitStatusDto>(`${this.API_BASE}/status`, { params: { path } })
      .pipe(apiResult());
  }
}

Project B consumes the exact same interface:

// Project B (React)

import type { GitStatusDto } from '@org/shared/contracts';

export const gitService = {
  getStatus: (path: string) =>
    apiResult(axios.get<GitStatusDto>(`${API}/status`, { params: { path } }).then((r) => r.data)),
};

Now add a new field to GitStatusDto. The TypeScript compiler immediately surfaces every file - across every project - that needs updating. All in the same build, from the same commit, before anything reaches production.

Compare this to the multi-repo alternative: update the types package, publish a new version, bump the dependency in Project A, open a PR, wait for review, merge, then repeat for Project B. If someone forgets to bump, the frontend silently ignores the new fields until a user reports something broken.

Shared Utilities: Same Logic, Tested Once

Beyond contracts, pure utility functions represent the next layer of high-value sharing:

// libs/shared/utils/src/index.ts

export * as FileUtils from './lib/file-utils/index';
export * as GitTreeUtils from './lib/git-tree-utils/git-tree.utils';
export * as MonacoUtils from './lib/monaco-utils/index';
export * as TabManager from './lib/tab-manager/tab-manager';
export * as ResizeUtils from './lib/resize-utils/resize-utils';
export { browserStorage } from './lib/browser-storage/browser-storage';
export { apiResult } from './lib/api-result/api-result';

GitTreeUtils.buildGitChangesTree() transforms flat git status data into a tree structure. It's used by the backend building the API response AND by frontend stores processing that response. Same function, same logic, tested once, maintained in one place.

MonacoUtils configures the Monaco code editor. TabManager handles open/close/reorder logic. browserStorage wraps localStorage. None of these depend on any framework - they're pure TypeScript that works everywhere.

In a multi-repo world, this kind of code either gets copy-pasted between projects (and slowly diverges) or gets published as an internal npm package (and becomes another thing to version, release, and keep in sync). In a monorepo, it's just an import.

What About Validation?

There's a tension worth addressing. Shared contracts are TypeScript interfaces - they exist only at compile time. But NestJS needs classes with runtime validation decorators to reject malformed requests. Frontends only need the type information. Where does validation logic live?

There are two solid approaches.

Approach A: Interfaces + Separate Validation Classes

The shared contract stays a pure interface. The NestJS backend creates a class that implements it and adds validation decorators:

// libs/shared/contracts (shared, pure interface)

export interface GitCommitRequestDto {
  message: string;
}

// apps/nestjs-api (backend only)

import { IsString, IsNotEmpty } from 'class-validator';
import type { GitCommitRequestDto } from '@org/shared/contracts';

export class GitCommitValidation implements GitCommitRequestDto {
  @IsString()
  @IsNotEmpty()
  message: string;
}

The implements keyword is key - if the interface changes, TypeScript forces the validation class to update too. The shared contract stays framework-agnostic. Frontends are completely unaffected.

The tradeoff is duplication: the interface says "message is a string" and the class repeats it with @IsString(). Validation rules live only in the backend.

Approach B: Zod Schemas as the Single Source of Truth

Instead of a plain interface, the shared contract exports a Zod schema. The TypeScript type is derived from the schema, so the shape and validation rules are defined once:

// libs/shared/contracts (shared, Zod schema)

import { z } from 'zod';

export const GitCommitRequestSchema = z.object({
  message: z.string().min(1, 'Commit message is required'),
});

export type GitCommitRequestDto = z.infer<typeof GitCommitRequestSchema>;
// → { message: string }

NestJS wraps the schema into a DTO using nestjs-zod:

// apps/nestjs-api (backend only)

import { createZodDto } from 'nestjs-zod';
import { GitCommitRequestSchema } from '@org/shared/contracts';

export class GitCommitDto extends createZodDto(GitCommitRequestSchema) {}

Frontends import the type exactly as before - no changes needed:

// Any frontend
import type { GitCommitRequestDto } from '@org/shared/contracts';

But they can also reuse the validation schema for client-side form validation:

// React form validation
import { GitCommitRequestSchema } from '@org/shared/contracts';

const result = GitCommitRequestSchema.safeParse(formData);
if (!result.success) {
  setErrors(result.error.format());
}

Both approaches work well in a monorepo. Approach A is simpler to adopt incrementally. Approach B pays off when validation consistency across the full stack matters.

Benefit 2: Enforced Standards - One Set of Rules for Everyone

With a multi-repo setup, each project develops its own conventions. Project A uses a feature-based folder structure, Project B organizes by file type. Project A handles HTTP errors through interceptors, Project C does it inline in every service call. State management looks completely different across projects - one uses signals, another still relies on BehaviorSubjects. Moving between projects becomes unnecessarily hard.

A monorepo eliminates this by sharing configuration files at the root level: one tsconfig.base.json, one ESLint config, one Prettier config. Every project inherits the same rules.

But shared config alone isn't enough. The real power comes from module boundary enforcement. Nx allows tagging every project by scope and type, then defining rules for what can depend on what:

// eslint.config.mjs

'@nx/enforce-module-boundaries': ['error', {
  depConstraints: [
    {
      sourceTag: 'type:app',
      onlyDependOnLibsWithTags: [
        'type:feature', 'type:ui', 'type:util',
        'type:data-access', 'type:contracts',
      ],
    },
    {
      sourceTag: 'type:ui',
      onlyDependOnLibsWithTags: ['type:ui', 'type:contracts', 'type:util'],
    },
    {
      sourceTag: 'type:util',
      onlyDependOnLibsWithTags: ['type:util', 'type:contracts'],
    },
    {
      sourceTag: 'type:data-access',
      onlyDependOnLibsWithTags: ['type:ui', 'type:util', 'type:contracts'],
    },
  ],
}]

In plain English:

A utility can only import other utilities and contracts. It can never reach up to a feature or a store.
A UI component can import other UI components, contracts, and utils. It cannot import stores or features. This keeps components pure and reusable.
Data-access stores can import utils and contracts. They cannot import features - keeping state management decoupled from view logic.
Features are the orchestrators. They wire stores to components and can import from all library types.

If someone writes an invalid import - say a UI component importing a data-access store - the linter catches it:

error  A project tagged with "type:ui" can only depend on libs tagged with
       "type:ui", "type:contracts", "type:util"
       @nx/enforce-module-boundaries

The PR can't merge. The architecture polices itself.

This is something no amount of documentation or code review discipline can achieve in a multi-repo. Rules that exist only in a wiki get ignored. Rules that break the build get followed.

Benefit 3: Build Only What Changed

The most common objection to monorepos is CI speed. "If everything is in one repo, doesn't every PR build everything?"

No. Nx traces the project dependency graph and runs tasks only for projects impacted by the change:

# CI pipeline - every pull request
- run: npx nx affected -t lint build --base=$NX_BASE --head=$NX_HEAD

nx affected compares the PR branch against the base, identifies changed files, walks the dependency graph to find impacted projects, and runs tasks only for those.

What Changed	What Gets Built
A feature in Project A	Only Project A and its dependencies
A shared contract	Every project that imports it
A shared utility	Only projects that depend on that utility
A README file	Nothing - no project depends on docs

On top of affected commands, Nx caches task results:

// nx.json

"targetDefaults": {
  "@angular/build:application": {
    "cache": true,
    "inputs": ["production", "^production"]
  },
  "@nx/js:swc": {
    "cache": true,
    "inputs": ["production", "^production"]
  }
}

The production named input excludes test files and configs. So editing a test file invalidates the test cache but not the build cache. The build replays from cache instantly.

With Nx Cloud, the cache becomes distributed - a build that ran on one developer's machine is available to the entire team and CI. The first person pays the cost; everyone else gets a cache hit.

Benefit 4: Atomic Deployments

In a multi-repo world, deployments are independent. The API deploys on Tuesday, Project A on Wednesday, Project B on Thursday. For two days, something is out of sync. If the API shipped a breaking change, Project B runs against the wrong contract version until someone notices.

A monorepo deploys everything from the same commit:

# deploy.yml - triggered on push to dev

- name: Lint
  run: npx nx affected -t lint

- name: Build Project A
  run: npx nx build angular-ide --configuration=production

- name: Build Project B
  run: npx nx build react-ide

- name: Build API
  run: npx nx build nestjs-api

- name: Deploy Project A
  run: rsync -avz --delete dist/apps/angular-ide/ deploy@server:/var/www/app/angular/

- name: Deploy Project B
  run: rsync -avz --delete apps/react-ide/dist/ deploy@server:/var/www/app/react/

- name: Deploy API
  run: rsync -avz apps/nestjs-api/dist/ deploy@server:/opt/api/

- name: Restart Services
  run: ssh deploy@server "cd /opt/api && docker compose up -d --build"

One push. One pipeline. Every project deployed from the same source of truth.

There's never a window where Project A expects a field the API hasn't deployed yet. There's no "which API version is this frontend running against?" question. Contracts match because they come from the same commit.

Benefit 5: Single Version Policy

External Dependencies

This might be the most underrated benefit. In a multi-repo world, each project has its own package.json. Over time, they drift. Project A upgrades to Angular 21. Project B is still on Angular 16 because no one had time to migrate. Project C is stuck on Angular 13 because it depends on a library that never updated. A developer moves from Project B to Project A and discovers that half the patterns they learned don't exist in the older version. A security patch lands for Angular 18+ only - and two of three projects can't receive it.

The same happens with every dependency. One project runs RxJS 7, another RxJS 6. One uses TypeScript 5.5 strict mode, another is on 4.9 with half the checks disabled. The node_modules across projects become parallel universes.

A monorepo has one package.json. One version of Angular. One version of RxJS. One version of TypeScript. When a framework upgrade happens, it happens everywhere at once. Every project gets the security patches, the performance improvements, and the new APIs at the same time. No project falls behind because "we'll migrate later" - later never comes.

This also simplifies onboarding. A new developer learns one set of APIs, one set of patterns, one set of tooling. There's no "which version does this project use?" question.

Internal Shared Code

The same principle applies to shared libraries within the repo. In multi-repo setups, shared packages need semantic versioning. Consumers need to bump dependencies. Breaking changes mean major version bumps, migration guides, and inevitably one project staying on the old version for months.

The worst case is the diamond dependency problem: Project A depends on Shared v2, Project B depends on Shared v1, and both talk to the same API. Two versions of the same types in play, and runtime behavior becomes unpredictable.

In a monorepo, this can't happen. There's one version of @org/shared/contracts - the one at HEAD. Every project uses it. A breaking change forces all consumers to update in the same commit. The reviewer sees the full picture in a single pull request.

Git history becomes meaningful across the full stack:

feat(git): add conflict detection

- Add `conflicted` field to GitStatusDto
- Update API to detect merge conflicts
- Add conflict indicators to Project A
- Add conflict indicators to Project B

One commit. Complete traceability. Reviewable and revertable as a unit.

Even Competing Frameworks Can Coexist

If shared contracts, enforced boundaries, and affected builds work across multiple projects that use the same framework - they also work across projects that use different frameworks.

The production codebase these examples come from runs Angular and React side by side. Two frameworks with fundamentally different paradigms. Angular uses dependency injection and observables. React uses hooks and promises. NestJS uses decorators and its own module system.

Yet they all import from @org/shared/contracts. They all share @org/shared/utils. They all get validated by the same ESLint rules and deployed by the same pipeline.

The same GitStatusDto flows from a NestJS controller decorated with @Get('status'), through an Angular service returning an Observable<ApiResult<GitStatusDto>>, and through a React service returning a Promise<ApiResult<GitStatusDto>>. Different HTTP clients, different paradigms, one interface governing the data shape everywhere.

If even competing frameworks can coexist in the same repo without stepping on each other - then two Angular projects sharing an auth module, three React apps sharing a design system, or five microservices sharing API contracts is a trivially simpler version of the same pattern.

The multi-framework case is the stress test. The single-framework, multi-project case is the easy win.

The Tradeoffs

This approach has real costs that should be weighed honestly:

Tooling investment. Nx has a learning curve - project tags, dependency constraints, named inputs all need upfront configuration. But this is a one-time cost that pays off on every PR after.

Shared code changes ripple. When a contract changes, every consuming project rebuilds and retests. But that's the point - you catch breakage in CI instead of in production.

Repository size grows. More code, more history in a single repo. But nx affected and distributed caching mean CI only builds what changed, regardless of repo size.

Team coordination on shared code. Merge conflicts increase when multiple teams touch the same shared libraries. But clear ownership and thin shared layers keep this manageable - and the alternative is silent divergence across repos.

Overhead for a single project. A monorepo with one application feels like unnecessary tooling. But most companies don't stay at one project forever. When the second project launches, the shared contracts, enforced boundaries, and build infrastructure are already in place.

About This Monorepo

The codebase used in this post (kod3.dev, source code) started as a portfolio project to showcase Nx and prove that even competing frameworks can coexist in a single repo. But it keeps growing as new ideas come in - voice control, AI integration, a terminal emulator - and the monorepo structure makes it easy to add features without reorganizing the entire project.

One thing worth noting: the libraries aren't split into dozens of tiny packages. A shared utils lib contains FileUtils, GitTreeUtils, MonacoUtils, TabManager, and more - all in one library. What keeps this manageable is named barrel exports:

// libs/shared/utils/src/index.ts

export * as FileUtils from './lib/file-utils/index';
export * as GitTreeUtils from './lib/git-tree-utils/git-tree.utils';
export * as MonacoUtils from './lib/monaco-utils/index';
export * as TabManager from './lib/tab-manager/tab-manager';
export * as ResizeUtils from './lib/resize-utils/resize-utils';

Consumers import FileUtils.getExtension() or GitTreeUtils.buildGitChangesTree() - the namespace makes it clear where every function comes from, even when multiple utilities live in the same library.

The tradeoff is that changing a single file in shared/utils triggers a rebuild of every project that depends on the library. When that becomes a problem - when one utility changes frequently and causes unnecessary rebuilds - that's the signal to split it into its own library. Named barrel exports make the code readable from the start, and Nx makes the split straightforward when the time comes. You don't need to start with fifty micro-libraries to end up with a clean architecture.

Getting Started

For teams considering this approach:

1. Start with contracts. Extract shared TypeScript interfaces into a dedicated library. This is the highest-leverage move - immediate type safety across every project that consumes the same API.

2. Add module boundaries early. Tagging projects from the start is straightforward. Untangling circular dependencies six months later is not.

3. Keep the shared layer thin. Share what must be shared: contracts, pure utility functions, and cross-cutting concerns. Project-specific logic stays in project-specific directories.

4. Namespace imports clearly. Path aliases like @org/shared/contracts, @org/project-a-data-access, and @org/project-b-ui make it immediately obvious which layer and project an import belongs to.

5. Visualize dependencies regularly. nx graph renders the project dependency graph. When an unexpected arrow appears, fix it while it's still one import to remove - not an architectural refactor.

Conclusion

A monorepo isn't about putting files in one folder. It's about creating a system where shared logic has one source of truth, standards are enforced by tooling instead of documentation, builds are intelligent enough to skip what hasn't changed, and deployments are atomic across every project.

The 20% of shared code in a well-structured monorepo isn't about reducing keystrokes. It's about ensuring that when a DTO changes, every consumer across every project updates together, breaks together, and ships together. The alternative - copy-pasted code, diverging conventions, staggered deployments, and runtime type mismatches - costs more than any monorepo tooling ever will.

If you're interested in the reusable signal store patterns from this codebase, I wrote about those in this post.