Forem: Simone Boccato

Angular - NgRx Facade Design Pattern

Simone Boccato — Mon, 20 Apr 2026 20:57:21 +0000

In this article I'll show how I use the Facade Design Pattern on my angular projects.

Facade Design Pattern

I read about this pattern from this website: facade
This is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.

The goal of the Facade is to provide a simple interface to complex subsystem which contain lots parts.

How to implement it

In my angular project’s signals-first architecture, the Facade pattern serves as a critical architectural layer between components and the underlying state management (NgRx Signal Store).

1. Define the State

First, we define the shape of our state and its initial values. Using a _ prefix for internal state properties is a common convention when we plan to rename them in the public API.

// auth.state.ts
export type LocaleModel = 'en' | 'it';
export type UserData = {
  email: string;
  firstName: string;
  lastName: string;
  name: string;
  local: LocaleModel;
  phone?: string;
  phonePrefix?: string;
  group: 'FREE' | 'PROFESSIONAL' | 'ENTERPRISE';
};

export type AuthState = {
  _locale: LocaleModel | null;
  _loggedUser: UserData | null;
};

export const initialAuthState: AuthState = {
  _locale: null,
  _loggedUser: null,
} as const;

2. Create the Signal Store

The store handles the "how" of state management. It manages private state and exposes derived state via computed signals.

import { computed } from '@angular/core';
import { signalStore, withComputed, withMethods, withState } from '@ngrx/signals';

export const AuthStore = signalStore(
  { providedIn: 'root' },
  withState(initialAuthState),
  withComputed((store) => {
    const $isFreeUser = computed(() => store._loggedUser()?.group === 'FREE');
    const $isProfessionalUser = computed(() => store._loggedUser()?.group === 'PROFESSIONAL');
    const $isEnterpriseUser = computed(() => store._loggedUser()?.group === 'ENTERPRISE');

    return {
      $isFreeUser,
      $isProfessionalUser,
      $isEnterpriseUser,
    };
  }),
  withMethods((store) => {
    const initialize = () => {};
    const changeSelectedLanguage = () => {};
    const setLoggedUser = () => {};
    const updateUser = () => {};
    const logout = () => {};

    return {
      initialize,
      changeSelectedLanguage,
      setLoggedUser,
      updateUser,
      logout,
    };
  }),
);

export type AuthStore = InstanceType<typeof AuthStore>;

3. Implement the Facade

The Facade provides the "what" to the components. We use the OmitSymbols utility to ensure the Facade strictly implements the functional API of the Store while automatically hiding internal NgRx Signal Store symbols that shouldn't be exposed to components.

// auth.facade.ts
import { inject, Injectable, type Signal } from '@angular/core';

/**
 * Drops every symbol-keyed property *plus* any keys in `U`.
 */
export type OmitSymbols<T, U extends PropertyKey = never> = {
  [K in keyof T as K extends symbol ? never : K extends U ? never : K]: T[K];
};

@Injectable({ providedIn: 'root' })
export class AuthFacade implements OmitSymbols<AuthStore> {
  readonly #authStore = inject(AuthStore);

  // Expose signals with $ prefix
  readonly $locale = this.#authStore._locale;
  readonly $loggedUser = this.#authStore._loggedUser;

  readonly $isFreeUser = this.#authStore.$isFreeUser;
  readonly $isProfessionalUser = this.#authStore.$isProfessionalUser;
  readonly $isEnterpriseUser = this.#authStore.$isEnterpriseUser;

  initialize() {
    this.#authStore.initialize();
  }
  changeSelectedLanguage() {
    this.#authStore.changeSelectedLanguage();
  }
  setLoggedUser() {
    this.#authStore.setLoggedUser();
  }
  updateUser() {
    this.#authStore.updateUser();
  }
  logout() {
    this.#authStore.logout();
  }
}

4. Use inside Angular Components

Components consume a clean, reactive API. They are decoupled from the store's implementation details.

  @Component({...})
  export class HeaderComponent {
    readonly #auth = inject(AuthFacade);

    // Direct access to signals from facade
    $user = this.#auth.$loggedUser; 
    $isFreeUser = this.#auth.$isFreeUser;

    onLogout() {
     this.#auth.logout();
    }
   }

Why this matters in real projects

Based on the AuthFacade pattern, here is why this is effective:

Abstraction of Complexity

Components shouldn't care how state is managed. The Facade hides the complexity of the AuthStore. If you decide to move a piece of state from a global Store to a specialized Service or even combine it with Route Params, you only update the Facade. Your components remain untouched.

Simplified Public API & Integrity

A Store often contains internal state and complex update logic. The Facade acts as a gatekeeper:

It exposes only what the component needs.
It protects the store's integrity by not exposing patchState or internal state directly.
It provides a semantic interface: this.#authFacade.logout() is clearer than interacting with store internals.

Simplified Testing

One of the biggest benefits is simplified unit testing. You can easily mock the AuthFacade in component tests without setting up a full NgRx Signal Store:

   { provide: AuthFacade, useValue: { $loggedUser: signal(mockUser), logout: vi.fn() } }

Enforcement of Naming Conventions

The Facade reinforces the project's reactive patterns. Consistently exposing signals with the $ prefix gives developers an immediate visual cue that they are working with a Signal, promoting a "Signals-First" mindset.

Orchestration & Derived State

Facades are perfect for orchestrating multiple sources, and they can combine data from a Signal Store, a Standard Service, and Route Params into a single computed signal, providing the component with exactly one object to bind to.

NgRx - Custom SignalStore Feature

Simone Boccato — Sat, 18 Apr 2026 19:27:34 +0000

If you’ve been working with NgRx SignalStore for a while, you’ve probably noticed a pattern: you keep writing the same pieces of code over and over again.

Logging state changes. Resetting the store to its initial state. Managing filters and exposing update methods. None of these are complex, but they show up in almost every store you create.

At first, it doesn’t feel like a problem. Copy, paste, tweak—move on. But as your application grows, this repetition starts to add up. What was once “just a few lines” becomes boilerplate scattered across your codebase, making things harder to maintain and easier to get wrong.

The issue isn’t duplication itself—it’s the absence of a shared abstraction for these recurring patterns.

And that’s exactly where custom SignalStore features come in.

In this article, I want to share a few Custom SignalStore feature that I commonly use.

withLogger

Creates a feature that logs every state change.

export function withLogger(name: string) {
  return signalStoreFeature(
    withHooks((store) => {
      const logger = inject(LOGGER);
      return {
        onInit() {
          watchState(store, (state) => {
            logger.debug(`${name} state changed`, state);
          });
        },
      };
    }),
  );
}

withReset

Creates a feature that exposes a reset method on the store, allowing it to reset its state to the initial value

export function withReset<T extends object>(initialState: T) {
  return signalStoreFeature(
    withMethods((store) => ({
      reset: () => patchState(store, { ...initialState }),
    })),
    withHooks((store) => {
      return {
        onDestroy: () => {
          store.reset();
        },
      };
    }),
  );
}

withFilters

Creates a feature that will expose filters and an updateFilters method to read and update the store's filter state

export const withFilters = <
  T extends Record<string, unknown>,
  State extends Record<string, unknown>,
  Props extends Record<string, unknown>,
  Methods extends Record<string, (...params: any[]) => unknown>,
>(
  initialFilters: T,
) => {
  return signalStoreFeature(
    { state: type<State>(), props: type<Props>(), methods: type<Methods>() },
    withState<T>(() => ({ ...initialFilters })),
    withComputed(() => {
      const filters = computed<T>(() => ({ ...initialFilters}));
      return { filters };
    }),
    withMethods((store) => {
      const updateFilters = (filters: Partial<T> = {}) => {
        const newFilters = { ...initialFilters, ...filters };
        if (!objectEquals(newFilters, store.filters())) {
          patchState<T>(store, newFilters);
        }
      };
      return { updateFilters };
    }),
  );
};

Use all the previous Custom SignalStore features

Now we can use these custom features like this:

// contacts.state.ts
export type ContactData = {
  id: string;
  email: string;
  firstName: string;
  lastName: string;
};

export declare const ContactType: {
  readonly USER: 'USER';
  readonly ADMIN: 'ADMIN';
};
export type ContactType = (typeof ContactType)[keyof typeof ContactType];

export type ContactFilters = {
  contactType: ContactType | null;
  search: string | null;
};

export type ContactsState = {
  contacts: ContactData[];
};

export const initialContactsFilters: ContactFilters = {
  contactType: null,
  search: null,
};

export const initialContactsState: ContactsState = {
  contacts: [],
};

// contacts.store.ts
export const ContactsStore = signalStore(
  withState(initialContactsState),
  withLogger('[CONTACTS STORE]'),
  withReset(initialContactsState),
  withFilters(initialContactsFilters),
  withMethods((store, contactService = inject(ContactsService)) => {
    const loadContacts = async () => {
      const filters = store.filters();
      const result = await lastValueFrom(contactService.loadContacts(filters));
      patchState(store, { contacts: result });
    };

    return {
      loadContacts,
    };
  }),
);

export type ContactsStore = InstanceType<typeof ContactsStore>;

Why this matters in real projects

In small examples, repeating a few lines of code doesn't seem like a big deal. But in real-world applications, you rarely have just one or two stores-you often have dozens.
If every store implements logging, reset logic, or filters slightly differently, it becomes harder to reason about behavior, onboard new developers, or refactor safely. Even small inconsistencies can lead to subtle bugs or unexpected side effects.
Custom SignalStore features help you standardize these patterns. Instead of rewriting the same logic multiple times, you define it once and reuse it everywhere. This reduces boilerplate, improves readability, and makes your stores more declarative—focused on what they do rather than how they do it.

It also makes evolution easier. If you need to change how logging works or update your filter logic, you do it in one place instead of hunting through the entire codebase.

Trade-offs

Of course, introducing custom SignalStore features isn’t free.

The first trade-off is abstraction overhead. For someone new to the codebase, it’s not always obvious what a custom feature does without jumping into its implementation. Overusing abstractions can make simple logic feel harder to follow.

There’s also a risk of over-engineering. Not every repeated line of code needs to become a reusable feature. If the abstraction is used only once or twice, it might add more complexity than value.

Another consideration is flexibility. When logic is centralized, it can become harder to handle edge cases that don’t fit the abstraction cleanly. You may end up adding configuration options that make the feature more complex than the original duplication.

The key is balance: extract patterns that are truly repeated and stable, but keep things simple when the benefit of abstraction isn’t clear.

I Rewrote Angular Component Store with Signals - And Cut the Complexity in Half

Simone Boccato — Fri, 17 Apr 2026 19:49:46 +0000

After 8+ years working with Angular, I thought I had state management figured out.
Than I rewrote one of my real-world stores using Signals, because I realize I was mostly managing complexity, not reducing it.

The Context

Like many Angular developers, I've used NgRx for years. When ComponentStore came out, it felt like the perfect balance:

Local state
Reactive patterns
Powerfull async handling

In this case, I was working on a fairly standard feature:

Load user data
Manage countries, provinces, cities
Handle cascading selections

Nothing fancy - but not trivial either.

At some point, I stopped and asked myself:

Am I solving complexity... or just managing it better ?

So I tried something simple: rewrite the same store using Signal Store (Angular 19+).

Component Store version

Following the standard pattern, we define:

Selectors
Updaters
Effects

Selectors

readonly cities$: Observable<Record<SectionGeographicalType, City[]>> = this.select(
  (state: PersonalDataState) => state.cities,
);

readonly personalDataInfo$: Observable<PersonalDataInfo | null> = this.select(
  (state) => state.personalDataInfo
);

Updaters

readonly setCityList = this.updater((state: PersonalDataState, updateCities: UpdateCities) => {
  return {
    ...state,
    cities: {
      ...state.cities,
      [updateCities.type]: updateCities.cities,
    },
    error: null,
  };
});

Effects

readonly selectedCountry = this.effect((selectCountry$: Observable<SelectCountryModel>) => {
  return selectCountry$.pipe(
    switchMap((selectCountry: SelectCountryModel) => {
      return forkJoin([
        this.countryService.getProvinceList(selectCountry.country.sk),
        of(selectCountry.type),
      ]);
    }),
    map(([response, type]) => {
      this.setCityList({ type, cities: [] });

      if (!response?.success) {
        this.setProvinceList({ type, provinces: [] });
        return EMPTY;
      }

      this.setProvinceList({ type, provinces: response.data ?? [] });
      return EMPTY;
    }),
    catchError((error: any) => {
      return selectCountry$.pipe(
        tap((selectCountry: SelectCountryModel) => {
          this.setCityList({ type: selectCountry.type, cities: [] });
          this.setProvinceList({ type: selectCountry.type, provinces: [] });
        }),
        map(() => EMPTY),
      );
    }),
  );
});

What's the Problem ?

Nothing. This is correct, scalable and idiomatic RxJS.
But here's the issue:

It's harder to read than it needs to be for this level of complexity

To understand the flow, you need to:

Mentally simulate streams
Jump between effects, updaters and selector
Track async behavior across operators

That's a cognitive cost.

Rewrite to Signal Store

export const PersonalDataStore = signalStore(
  { providedIn: 'root' },
  withState(initialPersonalDataState),
  withMethods(
    (
      store,
      countryService: CountriesService = inject(CountriesService),
      logger: LoggerService = inject(LoggerService),
      personalDataService: PersonalDataService = inject(PersonalDataService),
      serviceHttpService: ServiceHttpService = inject(ServiceHttpService),
      userHttpService: UserHttpService = inject(UserHttpService),
    ) => {
      const _updateCityList = (updateCities: UpdateCities) => {
        patchState(store, {
          cities: {
            ...store._cities(),
            [updateCities.type]: updateCities.cities,
          },
        });
      };

      const _updateProvinceList = (updateProvinces: UpdateProvinces) => {
        patchState(store, {
          provinces: {
            ...store._provinces(),
            [updateProvinces.type]: updateProvinces.provinces,
          },
        });
      };

      const _updateUser = (user: PersonalDataInfo | null) => {
        patchState(store, { personalDataInfo: user });
      };

      const loadInitialData = async (): Promise<void> => {
        const user: Response<User> = await lastValueFrom(userHttpService.getUser());
        const personalDataInfo: PersonalDataInfo | null = personalDataService.convertUserToFormModel(user.data);
        _updateUser(user.success ? personalDataInfo : null);
        const countries = await lastValueFrom(countryService.countries$);
        patchState(store, { countries: countries });
      };

      const selectedCountry = async (selectCountry: SelectCountryModel): Promise<void> => {
        try {
          _updateCityList({ type: selectCountry.type, cities: [] });
          const response = await lastValueFrom(serviceHttpService.getProvinceList(selectCountry.country.sk));

          if (!response?.success) {
            _updateProvinceList({ type: selectCountry.type, provinces: [] });
          } else {
            _updateProvinceList({ type: selectCountry.type, provinces: response.data ?? [] });
          }
        } catch (e) {
          _updateCityList({ type: selectCountry.type, cities: [] });
          _updateProvinceList({ type: selectCountry.type, provinces: [] });
        }
      };

      const selectedProvince = async (selectProvince: SelectProvinceModel) => {
        try {
          const response = await lastValueFrom(
            serviceHttpService.getCityList(selectProvince.province.countrySk, selectProvince.province.code),
          );
          if (!response?.success) {
            _updateCityList({ type: selectProvince.type, cities: [] });
          } else {
            _updateCityList({ type: selectProvince.type, cities: response.data ?? [] });
          }
        } catch (e) {
          _updateCityList({ type: selectProvince.type, cities: [] });
        }
      };

      return {
        loadInitialData,
        selectedCountry,
        selectedProvince,
      };
    },
  ),
);

export type PersonalDataStore = InstanceType<typeof PersonalDataStore>;

The Real Difference

This isn't about syntax. it's about how your brain process the code.
There are:

No streams to simulate
No operators no mentally execute
No indirection between layers

Just:

perform an action
update the state

The Trade-Off

This rewrite is not "free".
I intentionally moved from reactive streams to imperative async flows.

What I lost:

Built-in cancellation (e.g switchMap)
Stream composition
Reactive coordination across multiple sources

What I gained:

Linear, readable logic
Easier onboarding
Lower cognitive overhead

And for this feature, that trade-off was worth it.

When ComponentStore Still Wins

There are cases where RxJS is absolutely the right tool:

Complex async orchestration
Race conditions and cancellation
WebSocket or event streams
Combining multiple reactive sources

In those scenarios, Signals won't replace RxJS - they complement it.

Final Thought

We didn't remove reactivity.
We just chose a simpler model for a problem that didn't need the full power of RxJS, and in doing that, we reduce the cognitive load without sacrificing the outcome