Forem: Florian Spier

Two-way bind a Signal Input object value with [(ngModel)]

Florian Spier — Sat, 15 Feb 2025 11:11:00 +0000

Recently, I encountered this challenge... Refactor a form component to Angular Signals.

The old form component works like this:

The form data comes from a reactive state service
The form data is an object
The form data is cloned before it is passed to the form component
The form component receives the form data via one classic decorator-based Angular @Input

@Input({required: true})
user!: User;

The form is a template-driven form and uses [(ngModel)] to mutate the form data object

<div>
  <label for="firstName">First Name</label>
  <input id="firstName" name="firstName" [(ngModel)]="user.firstName" />
</div>

Clicking the save button would send the mutated object to the parent component via an Angular @Output
The parent component updates the reactive state service

This setup works great in many of our applications.

You can review this setup in this StackBlitz which showcases the basic principle: Form with classic Angular @Input

Refactor to Signal Input

With Angular Signal Input we can make our component inputs reactive. This sounds great!

FYI Signal Inputs are the recommended way for new projects. From the Angular docs:

Let's refactor our classic Angular @Input to a Signal Input:

user = input.required<User>();

Signal Input object value and [(ngModel)]

The Signal Input receives an object of type User. We try to bind to the object properties with [(ngModel)].

This code looks so nice 😍!

<div>
  <label for="firstName">First Name</label>
  <input 
    id="firstName" 
    name="firstName" 
    [(ngModel)]="user().firstName" 
  />
</div>

And in this StackBlitz everything seems to work: Form with Signal Input - mutating Signal State

‼️ Danger Zone:

But wait..., we have just entered the danger zone... ☢️ ☣️ ⚠️

What is actually happening?

user() unwraps the Input Signal. We get hold of the raw user object
This line of code [(ngModel)]="user().firstName" will mutate the user object (which is wrapped into a Signal) whenever the text input value changes

☢️ Mutating the Signal object ☣️

Why is mutating the Signal state a bad idea? Because we are bypassing the Signals public API to update state. Normally we should only use the dedicated methods set or update in order to update the Signal state.

Other developers might want to build other Signals on top of the user Signal with Angular computed. But computed will never be triggered because the user Signal does not know about the user object mutations. This might be a surprising behavior.

Signal Inputs are read-only

And yes, there is another reason, why using [(ngModel)] on a Signal Input is at least strange. Signal Inputs are supposed to be read-only. They do not have a set or update method - so there is no official support for changing Signal Input state programmatically.

Rescue

Let's try to escape as fast as possible 🚀. What are possible solutions?

Linked Signal

With Linked Signal we can create a writable user Signal, which is updated automatically, whenever the user Signal Input receives a new value. At the same time we can update the Linked Signal with set and update.

editableUser is our Linked Signal...

export class UserDetailComponent {
  user = input.required<User>();
  editableUser = linkedSignal(() => this.user()); 

  updateEditableUser(v: Partial<User>) {
    this.editableUser.update(state => ({...state, ...v}))
  } 
}

We also introduced a updateEditableUser method which uses the public Signal API to update the Signal state: in this case we call the update method of the Linked Signal.

<div>
  <label for="firstName">First Name</label>
  <input 
    id="firstName" 
    name="firstName" 
    [ngModel]="editableUser().firstName" 
    (ngModelChange)="updateEditableUser({firstName: $event})"
  />
</div>

[(ngModel)] has been split into [ngModel] and (ngModelChange)

[ngModel]="editableUser().firstName" will update the text input when the firstName property of the user object has been updated
whenever the text input value changes, the ngModelChange callback (updateEditableUser) will be executed and the Linked Signal will be updated

PROs

we use the public Signal API to update state
we use Linked Signal which is a writable signal
state changes happen explicitly in a dedicated method
object clone is not needed

CONs

There is some boilerplate necessary: Linked Signal setup, ngModel, ngModelChange, method for state update
At the moment, Linked Signal is still in developer preview (Angular 19)

StackBlitz: Form with Signal Input - Linked Signal

Effect

An alternative approach is using Angular effect to listen to new values of the Signal input.
When we receive a new value from the Input we assign the raw value to a local class property.

export class UserDetailComponent {
  _user = input.required<User>({alias: 'user'});
  user!: User;

  constructor() {
    effect(() => this.user = this._user())
  }
}

<div>
  <label for="firstName">First Name</label>
  <input 
    id="firstName" 
    name="firstName" 
    [(ngModel)]="user.firstName" 
  />
</div>

In the template we can mutate the raw object as we always did.

PROs

The template is identical to our original old-school form component which used a classic Angular @Input
We officially mutate a raw object (we do not bypass Signal APIs, we do not mutate the read-only Signal Input state).

CONs

user: User must be initialised: user: User = new User(); or we must tell TypeScript that user is always defined with user!: User;
cloning is needed (happens in the parent with the structuredClone pipe)
naming challenge: _user Signal, 'user' alias, user property for the raw user object

StackBlitz: Form with Signal Input - Effect

@let approach

With @let, we can declare variables in the template.

Let's use @let to get the raw object from the user Signal Input. Additionally, we can also perform the clone with our structuredClone pipe.

@let userClone = user() | structuredClone;

<div>
  <label for="firstName">First Name</label>
  <input 
    id="firstName" 
    name="firstName" 
    [(ngModel)]="userClone.firstName" 
  />
</div>

TypeScript:

export class UserDetailComponent {
  user = input.required<User>();
}

PROs

Minimum boilerplate, and smallest code change in comparison the old-school (@Input) form component
@let is the single place to let the magic happen (unwrap the Signal, clone)

CONs

Object value is required, it does not work with primitive values. See Notes below for more details
cloning is needed

StackBlitz: Form with Signal Input - @let

Notes

Object vs Primitive Values

In the examples above, the component Input received an object value (the user object).
The Linked Signal and Effect approaches would also work with Signal Inputs which use primitive values (string, boolean, number...).

Let's have a look at the @let approach:
@let variables are read-only... which means we can not reassign new values to a @let variable. Also, not via [(ngModel)]. If we try, then we can see this compile error:

The @let approach requires an object value, which we can mutate.

Conclusion

The "@let approach" seems to be the most straight-forward solution with a minimum of boilerplate.

Effect and Linked Signal are also valid options, but require more setup.

We are still evaluating which approach is most suited for our applications and this blogpost should help us to make a good decision.

I hope that you enjoyed our short visit to the danger zone of mutating Signal state. What do you think of my escape strategies? I am sure there are even more options. Let me know in the comments.

Thank you!

10 Reasons for MiniRx Signal Store

Florian Spier — Fri, 01 Mar 2024 12:33:11 +0000

The Angular renaissance is still ongoing. MiniRx is part of that renaissance and released a new Signal-based state management library for Angular: MiniRx Signal Store.

There are many reasons why MiniRx Signal Store is a great state management solution for Angular..., but these are the top ten reasons:

All-in-one solution: With MiniRx Signal Store you get three well-defined state containers out of the box.
- Manage global state at large scale with the Store (Redux) API
- Manage global state with a minimum of boilerplate using Feature Stores
- Manage local component state with Component Stores
Flexibility: All three state containers can be easily used together in your application. Depending on the use-case, you can choose the state container which suits your needs.
Highly integrated: MiniRx Signal Store was designed as an all-in-one solution from the beginning. This allows for a high level of integration:
- Feature Store uses the Redux Store under the hood
- Feature Store state integrates into the global state object of the Redux Store
- Feature Store automatically uses all the extensions of the Redux Store (e.g. Redux DevTools extension, ImmutableState extension)
- Feature Store and Component Store share the same API
Made for modern Angular: MiniRx Signal Store uses modern Angular APIs (e.g. Signal, DestroyRef) and offers deep integration with Angular.
New Angular best practices: MiniRx Signal Store implements and promotes new Angular best practices:
- Signals are used for (synchronous) state
- RxJS is used for events and asynchronous tasks
RxJS and Signals interop: MiniRx Signal Store streamlines your usage of RxJS and Signals: e.g. connect and rxEffect understand both Signals and Observables
Lightweight
Extendable: MiniRx Signal Store comes with powerful extensions:
- Immutable State Extension: Make your Signal state immutable to prevent mutating state accidentally.
- Redux DevTools Extension: inspect state and state changes at anytime in the Redux DevTools (available for the Redux Store and Feature Store).
- Undo Extension: Undo state changes.
- Logger Extension: Log actions and updated state in the JS console.
- You can easily create your own extensions!
OOP-style: Your fellow fullstack Angular developers, who are used to object-oriented programming (Java, .NET, ...) will love MiniRx Signal Store. MiniRx Signal Store exposes TypeScript classes which can be extended or used with new.
Framework-agnostic code: Although MiniRx Signal Store is an Angular library, your state management code is almost framework-agnostic. Signals are an internal implementation detail of the Signal Store. Therefore, you can easily refactor your state management layer to the original (RxJS-based) MiniRx Store and use it in whatever framework you want (e.g. Svelte).

You can try MiniRx Signal Store today

Install:

npm i @mini-rx/signal-store

Documentation: https://github.com/spierala/mini-rx-store/blob/master/libs/signal-store/README.md

Do you like MiniRx Signal Store?

Give it a star on GitHub:
⭐ MiniRx platform on GitHub

Thank you!

Thanks

Special thanks for reviewing this blog post:

Pieter van Poyer

Introducing MiniRx Signal Store

Florian Spier — Wed, 07 Feb 2024 08:30:57 +0000

In Angular 16, we got a new cool and shiny reactive primitive: Signal.

The introduction of Angular Signals is probably one of the most disruptive changes in recent years:

RxJS is no more?
Should I avoid RxJS and use Signals for everything?
Can Signals and RxJS Observables co-exist?
Are there new Angular best practices?

With these questions in mind, MiniRx started exploring Signals, on the search for new Angular best practices.

The result is a new Signal-based state management library:

MiniRx Signal Store

Signal Store is an Angular-only state management library
Signal Store embraces Angular Signals and leverages Modern Angular APIs internally
Signal Store implements and promotes new Angular best practices:
- Signals are used for (synchronous) state
- RxJS is used for events and asynchronous tasks
Signal Store streamlines your usage of RxJS and Signals: e.g. connect and rxEffect understand both Signals and Observables
Signal Store is based on the same great concept as the original (RxJS-based) MiniRx Store
- It is an all-in-one solution for global and local state, complex and simple state
- You get three well-defined state containers: Store (Redux), Feature Store and Component Store
- Highly flexible: Do you build complex and more simple features in the same application? You can choose the right state container individually for each feature.

Getting Started

Requirements

Angular >= 16
RxJS >= 7.4.0

Install

To install the @mini-rx/signal-store package, use your package manager of choice:

npm install @mini-rx/signal-store

API documentation

The MiniRx Signal Store API is documented in the README.

New Angular best practices in MiniRx Signal Store

The MiniRx Signal Store is implemented using new Angular best practices.
At the same time MiniRx Signal Store also promotes these best practices in its new API:

Signals are used for (synchronous) state
RxJS is used for events and asynchronous tasks

Let's read on to understand why MiniRx Signal Store made this choice...

Signals

In version 16, Angular introduced Signals as a new reactive primitive. Prior to this, RxJS was the go-to tool for managing state in a reactive manner.

Why Signals?

Signals in Angular have some advantages, compared to RxJS:

Write subscription-free code, even without using the async pipe
Easier to learn (no pipe, no operators, Signals are always synchronous)
Easier to compose derived state from other Signals with computed instead of RxJS combineLatest
Signals may enable more efficient Angular Change Detection in the future

Signals in MiniRx Signal Store

Hopefully, you agree that Signals are the new best choice for state!

MiniRx Signal Store definitely made the choice: it uses Angular Signal internally and exposes Signals via its public API:

The global state object of the Redux Store (which is also used by the Feature Store) is implemented as Angular Signal
public API: all three state containers have a select method: it returns an Angular Signal
Memoized selectors (used to select state from the global state object) are implemented using Angular computed

RxJS

You may ask: Why do we still need RxJS? We have Signals now!

It is true, we do not need RxJS anymore for state: it is time to say goodbye to BehaviorSubject!

But there is still an area where RxJS shines: events and asynchronous tasks.

Distinct events with RxJS Subject

Signals are not suited for events, because it is possible to miss events. See this little example using Angular effect:

StackBlitz

You might expect to see all state changes logged in effect, but that is not the case if Signal state is changed synchronously...

RxJS Subject is the better alternative: we are notified about every event (also the synchronous ones). See this example:

StackBlitz

Side effects and race-conditions

When using RxJS-based streams, we can trigger side effects like API-calls and handle race-conditions with RxJS flattening operators (mergeMap, switchMap, concatMap, exhaustMap).

More operators

There is no limit! RxJS has more than 100 operators which can be used to manipulate your streams.
But to be honest, even a small bunch of operators will take you far: debounceTime, distinctUntilChanged, map, filter, catchError, etc

RxJS in MiniRx Signal Store

Did you see the strengths of RxJS?

MiniRx Signal Store made its choice... use RxJS for events and asynchronous tasks:

The Action stream of the (Redux) Store represents a stream of Events: it is implemented as RxJS Subject
Effects: you can pipe the Action stream to trigger API calls (and use flattening operators to handle race-conditions)
The rxEffect APIs of Feature Store and Component Store are based on RxJS Subject

Fun fact: even the Component Store uses a small Redux implementation... it has its own (RxJS Subject) Action stream.

RxJS and Signal Interop

MiniRx Signal Store will help you to streamline the usage of RxJS Observables and Signals.
The goal is to eliminate any conversion code in your application: say goodbye to toSignal and to toObservable!

These MiniRx Signal Store APIs can handle both Observables and Signals:

`rxEffect`

rxEffect is used to trigger side effects like API calls in Feature Store and Component Store.
There are three different ways to trigger the side effect:

Raw Value
Signal
Observable

Following (Component Store) example uses an Angular Signal (Input) to trigger the API call:

import { Component, inject, input, Signal } from '@angular/core';
import { createComponentStore, tapResponse } from '@mini-rx/signal-store';
import { switchMap } from 'rxjs';
import { BookService } from '../book.service';

type State = {
  detail: BookDetail;
  isLoading: boolean;
}

const initialState: State = {
  detail: undefined,
  isLoading: false
}

@Component({
// ...
})
export class BookComponent {
  private store = createComponentStore(initialState);
  private bookService = inject(BookService);

  bookId = input.required<string>(); // Signal Input

  bookDetail: Signal<BookDetail> = this.store.select(state => state.detail);
  isLoading: Signal<boolean> = this.store.select(state => state.isLoading);

  // Create an Effect
  private loadDetail = this.store.rxEffect<string>(
    // Handle race-condition with switchMap
    switchMap(id => {
      this.store.setState({isLoading: true});

      return this.bookService.getBookDetail(id).pipe(
        tapResponse({
          next: (detail: BookDetail) => {this.store.setState({detail})},
          error: () => this.store.setState({isLoading: false})
        })
      )
    })
  )

  constructor() {
    // Fetch detail for every new bookId Signal value
    this.loadDetail(this.bookId)
  }
}

`connect`

Available in Feature Store, Component Store.

With connect you have the possibility to connect your store with external sources like Observables and Signals.
This helps to make your store the Single Source of Truth for your state.

We are connecting the Component Store to both Observable and Signal in this example:

import { Component, Signal, signal } from '@angular/core';
import { CommonModule } from '@angular/common';
import { createComponentStore } from '@mini-rx/signal-store';
import { timer } from 'rxjs';

@Component({
// ...
})
export class ConnectComponent {
  store = createComponentStore({
    counter: 0,
    counterFromObservable: 0, // Will be updated via Observable
    counterFromSignal: 0, // Will be updated via Signal
  });

  sum: Signal<number> = this.store.select((state) => {
    return state.counter + state.counterFromObservable + state.counterFromSignal;
  });

  constructor() {
    const interval = 1000;

    const observableCounter$ = timer(0, interval); // Observable
    const signalCounter = signal(0); // Signal

    // Connect external sources (Observables or Signals) to the Component Store
    this.store.connect({
      counterFromObservable: observableCounter$, // Observable
      counterFromSignal: signalCounter, // Signal
    });

    setInterval(() => signalCounter.update((v) => v + 1), interval);
  }

  increment() {
    this.store.setState((state) => ({ counter: state.counter + 1 }));
  }
}

All-in-one solution

With MiniRx Signal Store you get three well-defined state containers out of the box:

Manage global state at large scale with the Store (Redux) API
Manage global state with a minimum of boilerplate using Feature Stores
Manage local component state with Component Stores

The MiniRx Signal Store API is documented in the README.

Flexibility

All three state containers can be easily used together in your application.
Depending on the use-case, you can choose the state container which suits your needs.

See here the most typical use-cases:

Summary

These are exciting times for Angular: old best practices disappear, new ones have to be explored.
You saw MiniRx exploring Signals and RxJS. MiniRx Signal Store is the result of that exploration.

MiniRx Signal Store is an incredibly flexible state management solution:
It does not matter if you manage global or local state, complex or simple state... MiniRx Signal Store has you covered!

With its flexibility and new Angular best practices on board, MiniRx Signal Store will navigate you through modern Angular!

⭐ MiniRx on GitHub

Do you like MiniRx? Give it a GitHub star here.

Thank you! :)

Demos

MiniRx Signal Store was successfully tested in these projects:

Release

MiniRx Signal Store 1.0.0 was published today!

Thanks

Special thanks for reviewing this blog post:

Tomasz Ducin: twitter, ducin.dev

MiniRx Signal Store for Angular - API Preview

Florian Spier — Fri, 17 Nov 2023 15:14:47 +0000

MiniRx Signal Store is in the making...

🤓 See the Signal Store RFC on GitHub discussions: https://github.com/spierala/mini-rx-store/discussions/188
🤓 Signal Store Pull Request on GitHub: https://github.com/spierala/mini-rx-store/pull/195
A pre-release version can be loaded from npm: https://www.npmjs.com/package/@mini-rx/signal-store

What can we expect from MiniRx Signal Store?

Signal Store is an Angular-only state management library
Signal Store embraces Angular Signals and leverages Modern Angular APIs internally
Signal Store is based on the same great concept as the original MiniRx Store
- Manage global state at large scale with the Store (Redux) API
- Manage global state with a minimum of boilerplate using Feature Stores
- Manage local component state with Component Stores
- MiniRx always tries to find the sweet spot between powerful, simple and lightweight
Signal Store implements and promotes new Angular best practices:
- Signals are used for (synchronous) state
- RxJS is used for events and asynchronous tasks
Signal Store helps to streamline your usage of RxJS and Signals: e.g. connect and rxEffect understand both Signals and Observables
Simple refactor: If you used MiniRx Store before, refactor to Signal Store will be pretty straight-forward: change the TypeScript imports, remove the Angular async pipes (and ugly non-null assertions (!)) from the template

API Preview

Let's have a closer look at the Signal Store API.

Most APIs are very similar to the original MiniRx Store. We will focus here on the changed and new APIs.

Component Store and Feature Store

FYI Feature Store and Component Store share the same API (just their internal working and their use-cases are different).

In the examples below we look at Component Store, but you can expect the same API changes for Feature Store.

All code examples can be found back in this StackBlitz.

select

select is used to select state from your Component Store.

You can probably guess it already..., the select method returns an Angular Signal.

Example:

import { Component, Signal } from '@angular/core';
import { createComponentStore } from '@mini-rx/signal-store';

@Component({
// ...
})
export class SelectDemoComponent {
  private cs = createComponentStore({counter: 1});
  doubleCounter: Signal<number> = this.cs.select(state => state.counter * 2)
}

Read the Signal like this in the template:

<pre>
  doubleCount: {{doubleCounter()}},
</pre>

The select method is exposed by Store, Feature Store and Component Store.

StackBlitz demo: SelectDemoComponent

setInitialState

There is no setInitialState method anymore in Feature Store/Component Store for lazy state initialisation.
An initialState is now always required by Feature Store and Component Store, which is more inline with native Angular Signals.

connect

The connect method is new! With connect you can connect your store with external sources like Observables and Signals.
This helps to make your store the Single Source of Truth for your state.

FYI setState does not support an Observable parameter anymore, use connect instead.

Example:

import { Component, signal } from '@angular/core';
import { ComponentStore, createComponentStore } from '@mini-rx/signal-store';
import { timer } from 'rxjs';

interface State {
  counterFromObservable: number;
  counterFromSignal: number;
}

@Component({
// ...
})
export class ConnectDemoComponent {
  cs: ComponentStore<State> = createComponentStore<State>({
    counterFromObservable: 0,
    counterFromSignal: 0,
  });

  constructor() {
    const interval = 1000;

    const observableCounter$ = timer(0, interval); // Observable
    const signalCounter = signal(0); // Signal

    // Connect external sources (Observables or Signals) to the Component Store
    this.cs.connect({
      counterFromObservable: observableCounter$, // Observable
      counterFromSignal: signalCounter, // Signal
    });

    setInterval(() => signalCounter.update((v) => v + 1), interval);
  }
}

Access the Signals in the Component template:

<!-- Access top level state properties easily from the cs.state Signal -->
<ng-container *ngIf="cs.state() as state">
  <pre>
    counterFromRxJS: {{ state.counterFromObservable }}, 
    counterFromSignal: {{ state.counterFromSignal }}
  </pre>
</ng-container>

StackBlitz demo: ConnectDemoComponent

rxEffect

The effect method has been renamed to rxEffect (to avoid confusion with the Angular Signal effect function).

Feature Store and Component Store expose the rxEffect method to trigger side effects like API calls.

rxEffect returns a function which can be called later to start the side effect with an optional payload.

In the following example you can see that you can trigger the side effect with a Raw Value, an Observable and of course a Signal:

import { Component, signal } from '@angular/core';
import { FormControl, ReactiveFormsModule } from '@angular/forms';
import { createComponentStore, tapResponse } from '@mini-rx/signal-store';
import { of, Observable, map, switchMap, delay } from 'rxjs';

function apiCall(filter: string): Observable<string[]> {
// ...
}

interface State {
  cities: string[];
}

@Component({
// ...
})
export class EffectDemoComponent {
  cs = createComponentStore<State>({
    cities: [],
  });

  private fetchCitiesEffect = this.cs.rxEffect<string>(
    switchMap((filter) => {
      return apiCall(filter).pipe(
        tapResponse({
          next: (cities) => this.cs.setState({ cities }),
          error: console.error,
        })
      );
    })
  );

  formControl = new FormControl();
  private filterChangeObservable$ = this.formControl.valueChanges; 
  private filterChangeSignal = signal('');

  constructor() {
    // Observable
    // Every emission of the Observable will trigger the API call
    this.fetchCitiesEffect(this.filterChangeObservable$);
    // Signal
    // The Signals initial value will immediately trigger the API call
    // Every new Signal value will trigger the API call
    this.fetchCitiesEffect(this.filterChangeSignal); 
  }

  triggerEffectWithSignal() {
    // Update the Signal value
    this.filterChangeSignal.set('');

    setTimeout(() => {
      this.filterChangeSignal.set('a');
    }, 1000);

    setTimeout(() => {
      this.filterChangeSignal.set('c');
    }, 2000);
  }

  triggerEffectWithRawValue() {
    // Trigger the API call with a raw value
    this.fetchCitiesEffect('Phi');
  }
}

Component template:

<!-- Access top level state properties easily from the cs.state Signal -->
<ng-container *ngIf="cs.state() as state"> 
  <label>Trigger Effect with RxJS Observable (FormControl.valueChanges):</label>
  <input [formControl]="formControl" placeholder="Search city...">
  <pre>cities: {{state.cities | json}}</pre>  

  <button (click)="triggerEffectWithSignal()">Trigger Effect with Signal</button><br>
  <button (click)="triggerEffectWithRawValue()">Trigger Effect with Raw Value</button>
</ng-container>

StackBlitz demo: EffectDemoComponent

Component Store destruction

With Signal Store you can safely create a Component Store inside components. The Component Store will be automatically destroyed together with the component.

This is possible because the Component Store uses Angular DestroyRef internally.

Example: Child component with a local Component Store. The child component visibility is toggled in the parent component.

@Component({
  // ...
})
export class DestroyDemoChildComponent {
  // Create a local Component Store
  cs = createComponentStore({counter: 1}); 

  constructor() {
    // Connect a RxJS timer to the Component Store
    this.cs.connect({counter: timer(0, 1000).pipe(
      tap(v => console.log('timer emission:', v)) // We can see the logging WHILE the ChildComponent is visible (see the JS console)
    )})
  }
}

When the child component is destroyed, the Component Store will be destroyed as well.
The cleanup logic of Component Store will be executed which unsubscribes from all internal subscriptions (which includes the timer subscription).

StackBlitz demo: DestroyDemoChildComponent

Immutable Signal state

When using Angular Signals you can bypass the Signal update or set methods and mutate state at anytime.

This can cause unexpected behaviour and bugs.

MiniRx Signal Store comes with the ImmutableState Extension to prevent mutations (which exists also in the original MiniRx Store).

If you accidentally mutate the state, an error will be thrown in the JS console.

@Component({
// ...
})
export class ImmutableDemoComponent {
  private signalState = signal({counter: 1});
  counterFromSignal = computed(() => this.signalState().counter);

  cs = createComponentStore({counter: 1}, {
    extensions: [new ImmutableStateExtension() // FYI you could add extensions globally with `provideComponentStoreConfig` in main.ts
  ]});
  counterFromComponentStore = this.cs.select(state => state.counter);

  // SIGNAL
  // valid state update
  incrementSignalCounter() {
    this.signalState.update(state => ({...state, counter: state.counter + 1}))
  }

  // Signal Mutations
  // no error, you are entering danger zone, without knowing it
  mutateSignalA() {
    this.signalState().counter = 666;
  }

  mutateSignalB() {
    this.signalState.update(state => {
      state.counter = 666;
      return state;
    })
  }

  // COMPONENT STORE
  // valid state update
  incrementComponentStoreCounter() {
    this.cs.setState(state => ({counter: state.counter + 1}))
  }

  // Component Store Signal Mutations
  // As expected, mutating state will throw an error
  mutateComponentStoreSignalA() {
    this.cs.state().counter = 666; 
  }

  mutateComponentStoreSignalB() {
    this.cs.setState(state => {
      state.counter = 666;
      return state;
    })
  }
}

StackBlitz demo: ImmutableDemoComponent

Memoized Signal Selectors

createSelector, createFeatureStateSelector and createComponentStateSelector return a SignalSelector function.
Signal Selector functions take a Signal and return a Signal.

You can pass Signal Selectors to the select method of Store, Feature Store and Component Store.

Signal Selectors are memoized for fewer computations of the projector function.

Fun fact: Angular Signal computed is used to implement Signal Selectors.

Example: Selecting state from the Redux Store

import { Component, inject, Signal } from "@angular/core";
import { createFeatureStateSelector, createSelector, Store } from "@mini-rx/signal-store";
import { Todo, TodosState } from "./todo-state";

// Memoized SignalSelectors
const getFeature = createFeatureStateSelector<TodosState>('todos');
const getTodos = createSelector(getFeature, state => state.todos);
const getTodosDone = createSelector(getTodos, todos => todos.filter(item => item.isDone))
const getTodosNotDone = createSelector(getTodos, todos => todos.filter(item => !item.isDone))

@Component({
// ...
})
export class MemoizedSignalSelectorsDemoComponent {
  private store = inject(Store); // Store is provided in the main.js file
  todosDone: Signal<Todo[]> = this.store.select(getTodosDone);
  todosNotDone: Signal<Todo[]> = this.store.select(getTodosNotDone);
}

Access the Signals in the Component template:

<pre>DONE: {{ todosDone() | json }}</pre>
<pre>NOT DONE: {{ todosNotDone() | json }}</pre>

StackBlitz demo: MemoizedSignalSelectorsDemoComponent

Store (Redux)

Let's have a quick look at the API changes of the Store (Redux) API...

select

select is used to select state from your store. The select method returns an Angular Signal.

We can look again at the memoized selectors example to see select in action:

import { Component, inject, Signal } from "@angular/core";
import { createFeatureStateSelector, createSelector, Store } from "@mini-rx/signal-store";
import { Todo, TodosState } from "./todo-state";

@Component({
// ...
})
export class MemoizedSignalSelectorsDemoComponent {
  private store = inject(Store); // Store is provided in the main.js file
  todosDone: Signal<Todo[]> = this.store.select(getTodosDone);
  todosNotDone: Signal<Todo[]> = this.store.select(getTodosNotDone);
}

createRxEffect

The (Redux) Store effects API is pretty much unchanged. Just createEffect has been renamed to createRxEffect. The new name clearly indicates that the method is used in relation to RxJS Observables.

Small example from the Signal Store RFC:

import {
    Actions,
    createRxEffect,
    mapResponse,
} from '@mini-rx/signal-store';
import { ofType } from 'ts-action-operators';

@Injectable()
export class ProductsEffects {
  constructor(private productService: ProductsApiService, private actions$: Actions) {}

  loadProducts$ = createRxEffect(
    this.actions$.pipe(
      ofType(load),
      mergeMap(() =>
        this.productService.getProducts().pipe(
          mapResponse(
            (products) => loadSuccess(products),
            (error) => loadFail(error)
          )
        )
      )
    )
  );
}

Standalone APIs

MiniRx Signal Store got modern Angular standalone APIs.

Here is a quick overview:

provideStore: Set up the Redux Store with reducers, metaReducers and extensions
provideFeature: Add a feature state with a reducer (via the route config)
provideEffects: Register effects (via the route config)
provideComponentStoreConfig: Configure all Component Stores with the same config

FYI In module-based Apps you can still use the classic API: StoreModule.forRoot(), StoreModule.forFeature(), EffectsModule.register() and ComponentStoreModule.forRoot().

Feedback

We hope that you like the upcoming Signal Store!

If you see things which could be better or different, please let us know and leave a comment.

You can also contribute to Signal Store by commenting on the RFC or Pull Request on GitHub.

Thanks

Special thanks for reviewing this blog post:

Pieter van Poyer

Angular and RxJS on Mastodon

Florian Spier — Sat, 26 Nov 2022 07:12:58 +0000

TLDR While Elon Musk is doing his best to destroy Twitter, I created my new social media presence on Mastodon. Follow me on Mastodon for great Angular and RxJS content!

I used to be quite active on Twitter and found there a very nice Angular community. I learned a lot from the great people there and sometimes somebody could even learn from me. :) It was super cool and fun there!

But since Elon Musk took over, I have totally lost my motivation to post on Twitter. Twitter is not the same place anymore. And most importantly, the owner of my main social media platform shouldn't be crazy!

Last Resort: Mastodon

I find Mastodon very interesting... It is open source. Everyone of us can help to shape it. No crazy person can ever own it.

For me, it is time to move on, and Mastodon could be the right place.

After hanging out on Mastodon for a few weeks, I can say: it feels great, a breath of fresh air!

I like

Some things which I like about Mastodon:

500 characters: It is easier to write something useful with more insight. It feels much more like writing a small blog post.
Edit posts: I used that a lot already :) Fixing typos or improving the content.
Timeline without algorithm. The timeline is just sorted chronologically. That gives me peace. You can also not see "likes" directly: You can not judge a post by its "likes/retweets" at first sight. The content matters more.

Room for improvement

There are also some issues which should be mentioned:

More difficult to register: You have to find a Mastodon server which suits your needs. There are some criteria to consider: moderation, server rules, server location, interests of the users, number of users, how long does the server exist already, do I trust the server admin. Some people have a hard time to choose a server. I feel you! But at the same time the server does not matter too much. You can move to another server whenever you want.
It is not so straightforward to follow people from other Mastodon servers. You have to visit your own Mastodon server and copy paste their Mastodon handle in the search input.
There is still a lack of interaction, but that should be a question of time. In my early Twitter days, I was shouting into the void as well :)

My Angular and RxJS content on Mastodon

My posts on Mastodon are mostly about Angular and RxJS.

Here is a small selection of my more interesting posts on Mastodon:

Angular community on Mastodon

Several well-known people from the Angular community are present on Mastodon already! Find them back in this post:

A thread about finding Angular people on Mastodon

In the replies to the post you can find even more!

And you? I hope to see you soon on Mastodon as well! Together we can make Mastodon a great place!

Florian

MiniRx Feature Store vs. NgRx Component Store vs. Akita

Florian Spier — Tue, 30 Nov 2021 07:44:29 +0000

MiniRx "Feature Stores" offer simple yet powerful state management.
How does MiniRx Feature Store compare to @ngrx/component-store and @datorama/akita? 10 rounds in the fighting ring will bring clarity!

Disclaimer: I am the maintainer of MiniRx Store, I try to be fair, but it can be difficult from time to time.
To be clear: Component Store and Akita are great state management libraries. It will be an intense fight, but I will make sure that nobody gets hurt!

What is MiniRx?

MiniRx is a full-blown Redux Store powered by RxJS: It includes actions, reducers, meta reducers, memoized selectors, effects and Redux DevTools support.

The Redux pattern is great to manage state at large scale, but it forces us to write boilerplate code (actions, reducers, dispatch actions). This can be overkill for simple features in your application.

For that reason, MiniRx Feature Store offers a more simple form of state management: we can bypass Redux boilerplate and interact directly with a corresponding feature state with the FeatureStore API:

setState() update the feature state
select() select state from the feature state object as RxJS Observable
effect() run side effects like API calls and update feature state
undo() easily undo setState actions (requires the UndoExtension)
get state() imperatively get the current feature state

MiniRx scales nicely with your state management requirements:

Make hard things simple with the Redux Store API
Keep simple things simple with the FeatureStore API

In most cases you can default to the FeatureStore API and fall back to the Redux Store API to implement the really complex features in your application.

How does the Feature Store work?

Feature Store uses Redux under the hood:
Behind the scenes a Feature Store is creating a feature reducer and a corresponding setState action.
The feature reducer is registered in the Redux Store and the Feature Store state becomes part of the global state object.
When calling setState() the Feature Store dispatches its setState action (with the new state as action payload) and the feature reducer will update the feature state accordingly.

See the FeatureStore source here.

MiniRx Feature Store vs. NgRx Component Store vs. Akita

Let's shed some light on MiniRx Feature Store by sending it to the fighting ring together with two other popular state management libraries: @ngrx/component-store and @datorama/akita.

The competitors

NgRx Component Store (13.0.1)

Component Store is a library that helps to manage local/component state. It can be used as an alternative to the "Service with a Subject" approach.
It is build on top of RxJS/ReplaySubject (see here). Services which extend ComponentStore expose state as RxJS Observables (using the select method). With the methods setState and patchState the state can be updated.

Docs: https://ngrx.io/guide/component-store

Akita (6.2.4)

Akita describes itself as a "state management pattern":
It offers a set of specialized classes like Store, Query, EntityStore and more.
Akita Store is build on top of RxJS/BehaviorSubject (see here).
By using the Akita classes we can build a reactive state service which exposes state as RxJS Observables (using select on a Query instance). The update method of Store is used to update the state.

Docs: https://datorama.github.io/akita/

MiniRx Feature Store (3.0.0)

MiniRx itself is a "hybrid" Store. It uses Redux and RxJS/BehaviorSubject (see here) under the hood and exposes the powerful Redux Store API (which is very similar to @ngrx/store and @ngrx/effects).
At the same time MiniRx allows you to bypass the infamous Redux boilerplate with the FeatureStore API.
You can create a reactive state service by extending FeatureStore.
RxJS Observables (returned by the select method) inform about state changes and the state can be changed by calling setState.

Docs: https://mini-rx.io/docs/fs-quick-start

Mhhh..., this sounds all very similar, but where are the differences then? It's time to prepare the fighting ring! :)

FIGHT!

10 rounds to go!

1. Basic Setup

What does the basic setup of a reactive state service look like?

All setups share the same ingredients: A state interface and initial state.

FYI: The state interface must be object-like: you can not state-manage just a plain number or string.

interface CounterState {
    count: number;
}

const initialState: CounterState = {
    count: 42
}

MiniRx Feature Store

The state service extends FeatureStore:

@Injectable({providedIn: 'root'})
export class CounterStateService extends FeatureStore<CounterState> {

    count$: Observable<number> = this.select(state => state.count);

    constructor() {
        super('counter', initialState)
    }

    increment() {
        this.setState(state => ({count: state.count + 1}))
    }

    decrement() {
        this.setState(state => ({count: state.count - 1}))
    }
}

MiniRx Feature Store has to provide the initial state and a feature key: "counter".
The key is used to register the "counter" state in the global state object.

Component Store

With Component Store we extend ComponentStore and provide an initial state:

@Injectable({providedIn: 'root'})
export class CounterStateService extends ComponentStore<CounterState> {

    count$: Observable<number> = this.select(state => state.count);

    constructor() {
        super(initialState)
    }

    increment() {
        this.setState(state => ({count: state.count + 1}))
    }

    decrement() {
        this.setState(state => ({count: state.count - 1}))
    }
}

The Component Store setup looks very similar to Feature Store, however the feature key is not needed because every ComponentStore instance lives independently.
FYI: The Component Store initial state parameter is optional (see docs here).

Akita

With Akita, we create two services: One extends Store and the other one extends Query:

@Injectable({providedIn: 'root'})
@StoreConfig({ name: 'counter' })
export class CounterStateService extends Store<CounterState> {
    constructor() {
        super(initialState)
    }

    increment() {
        this.update(state => ({count: state.count + 1}))
    }

    decrement() {
        this.update(state => ({count: state.count - 1}))
    }
}

@Injectable({providedIn: 'root'})
export class CounterQuery extends Query<CounterState> {
    count$: Observable<number> = this.select(state => state.count);

    constructor(store: CounterStateService) {
        super(store);
    }
}

The Akita setup is the most boilerplaty. Extending Store is similar to the other setups. A feature key is provided via the @StoreConfig decorator.
To access the state you have to extend Query and provide the Store instance.
Also, the components have to talk to both the Query and the Store instance in order to read and write state.

2. Bundle Sizes

Regarding the basic setup..., let's look at the corresponding bundle sizes (using source-map-explorer).

MiniRx Feature Store

combined: 152.39 KB

Component Store

combined: 152.25 KB

Akita

combined: 151.61 KB

Akita is the most lightweight, and MiniRx is almost 1 KB bigger.
But keep in mind that MiniRx Feature Store uses Redux under the hood
and the Redux API is always available. Using the MiniRx Redux API will not add much to the total bundle size.

2.1. Bundle Sizes when adding Redux

MiniRx Feature Store + Store API (Store + Effects) using Angular Integration (mini-rx-store-ng)

combined: 156.9 KB

NgRx Component Store + NgRx Store

combined: 164.17 KB

NgRx Component Store + NgRx Store + NgRx Effects

combined: 171.45 KB

You can review the different setups in this repo and run source-map-explorer yourself: https://github.com/spierala/mini-rx-comparison

3. Local or global state

How do the different store solutions relate to local (component state) and global state? What is the store lifespan?

MiniRx Feature Store

MiniRx at its heart is a Redux Store with one global state object ("Single source of truth"). Also, MiniRx Feature Stores register a "slice" of state into the global state object.
The focus of MiniRx is clearly global state which has the lifespan of the application.

But Feature Stores are destroyable... Their state can be removed from the global state object. Therefore, Feature Stores can be used for "Local Component State", which has the lifespan of a component.

See an example in the MiniRx Angular demo.

Component Store

Component Stores live independently and are not related to something like a global state (e.g. when using @ngrx/store).
The lifespan of a Component Store can be bound to a component ("Local Component State"), but it can also take the lifespan of the application.

Akita

The Akita Stores live independently next to each other. There is no real global state. You can use Akita Stores (which are destroyable too) for "Local Component State" following this guide from the Akita docs.

4. Redux DevTools

MiniRx Feature Store

MiniRx can use Redux DevTools with the built-in Redux DevTools Extension.
Every Feature Store state becomes part of the global state object, and it can be inspected with the Redux DevTools.

Component Store

There is no official solution for Redux DevTools with Component Store.

Akita

Akita has a PlugIn for Redux DevTools support.
FYI: The separate Store states are merged into one big state object to make all state inspectable with the Redux DevTools. See the Akita DevTools source here.

5. Cross-state selection

How can we select state from other store instances and pull that state into our current store (state service)?

MiniRx Feature Store

Every Feature Store state integrates into the global state object. Therefore, the corresponding feature states can be selected at anytime from the Redux Store(!) instance using store.select.
Alternatively you can use RxJS combination operators like combineLatest or withLatestFrom to combine state from other Feature Stores with state Observables of your current Feature Store.

Component Store

The Component Store select method also accepts a bunch of Observables to depend on (see docs here).
Of course these Observables can come from other services. Like this it is straight-forward to depend on (observable) state of other ComponentStore instances.

Akita

Akita has combineQueries to combine state from different Query instances. combineQueries is basically RxJS combineLatest.
See the Akita combineQueries source here.

6. Memoized Selectors

Memoized selectors can help to improve performance by reducing the number of computations of selected state.
The selectors API (createSelector) is also great for Composition: Build selectors by combining existing selectors.

Examples for memoized selectors:

MiniRx Feature Store

MiniRx comes with memoized selectors out-of-the-box.
You can use the same createFeatureSelector and createSelector functions for the Redux Store API and for the FeatureStore API.

Example code of memoized selectors in the MiniRx Angular Demo: Todos State Service

Component Store

There is no official solution for Component Store.
You could add @ngrx/store to use the memoized selectors, but it would probably be overkill to add the NgRx Redux Store just for that reason. Redux Reselect could be a better alternative.

Akita

No memoized selectors. You could most probably add Redux Reselect.

7. Effects

Effects are used to trigger side effects like API calls.
We can also handle race-conditions more easily within an Effect by using RxJS flattening operators (switchMap, mergeMap, etc.).

MiniRx Feature Store

MiniRx Feature Store has Effects (https://mini-rx.io/docs/effects-for-feature-store).

FYI: Feature Store Effects have their equivalent in the Redux API of MiniRx: https://mini-rx.io/docs/effects

Component Store

Yes, there are Effects: https://ngrx.io/guide/component-store/effect

Akita

Yes, there are Effects: https://datorama.github.io/akita/docs/angular/effects.
Effects come with a separate package (@datorama/akita-ng-effects).
The Effects API is not tied to a Store instance.

8. Undo

How can we undo state changes?

MiniRx Feature Store

MiniRx has the UndoExtension to support Undo of state changes.
This is especially helpful if you want to undo optimistic updates (e.g. when an API call fails). Both the FeatureStore and the Redux Store API can undo specific state changes.
Feature Store exposes the undo method.

Read more in the MiniRx docs: Undo a setState Action

Component Store

No support for undo.

Akita

Akita has a State History PlugIn to undo state changes (https://datorama.github.io/akita/docs/plugins/state-history/).
The API is much bigger than the one of Feature Store. But it seems to be difficult to undo a very specific state change (which is important when undoing optimistic updates).

9. Immutable State

Immutability is key when using state management: We only want to allow explicit state changes using the corresponding API (e.g. by using setState, update or by dispatching an Action in Redux).
Mutating state however, might lead to unexpected behavior and bugs.
Immutable state helps to avoid such accidental state changes.

MiniRx Feature Store

MiniRx offers the Immutable State Extension to enforce immutable data.
When the ImmutableStateExtension is added to the MiniRx Store both the Redux Store API and the FeatureStore API will use immutable data.
The Immutable State Extension "deepfreezes" the global state when state is updated. Mutating state will throw an exception.

Component Store

There is nothing in Component Store which can enforce immutability.

Akita

Akita "deepfreezes" the state object when state is updated (only in DEV mode). See the corresponding source code here: https://github.com/datorama/akita/blob/v6.2.0/libs/akita/src/lib/store.ts#L181

10. Framework-agnostic

MiniRx Feature Store

MiniRx is framework-agnostic. You can use MiniRx with any framework or even without framework.

See here the MiniRx Svelte Demo: https://github.com/spierala/mini-rx-svelte-demo

Component Store

Component Store is tied to Angular. Angular is a peer dependency in the package.json.

Akita

Akita is also framework-agnostic. You can see in this article how Svelte and Akita play together: Supercharge Your Svelte State Management with Akita

Yes, you made it! I hope that you had fun to watch this fight!

Conclusion

All competitors showed their skills, none of them went to the ground!

Who was your favorite?

Give it a star on GitHub:

Notes

What did we not cover?

For completeness, I want to list a few things that were out of scope for this fight:

Akita: EntityStore, Transactions, Akita Immer, Persist State, CLI
Component Store: updater method, tapResponse operator

@rx-angular/state

Another cool lib which goes into the same direction as NgRx Component Store:
https://github.com/rx-angular/rx-angular/blob/master/libs/state/README.md

Maybe see you in the next fight! :)

Thanks

Special thanks for reviewing this blog post:

Michael Rutzer - diePartments

Articles which inspired me:

There was once a legendary fight in 2018, organized by Orjan de Smet: NGRX VS. NGXS VS. AKITA VS. RXJS: FIGHT!

Photos:

Photo by Attentie Attentie on Unsplash
Photo by Dan Burton on Unsplash
Photo by Matthew Payne on Unsplash

Introducing MiniRx - Scalable reactive state management

Florian Spier — Fri, 26 Feb 2021 13:07:13 +0000

Hello from MiniRx Store

MiniRx Store is the new kid on the reactive state management block. MiniRx will help you to manage state at large scale (with Redux), but it also offers a simple form of state management: Feature Stores.

Let's get a quick overview:

Global

MiniRx Store is a global, application-wide solution to manage state in JavaScript and TypeScript applications.

Reactive

MiniRx is powered by RxJS and exposes state as RxJS Observables. The Observables emit when their selected state changes.

Scalable

MiniRx is a full-blown Redux Store: It includes actions, reducers, meta reducers, memoized selectors and redux dev tools support.
However, with MiniRx Feature Stores we can bypass Redux boilerplate: update state straight away with setState.

MiniRx scales nicely with your state management requirements:

Make hard things simple with the Redux API
Keep simple things simple with the Feature Store API

Quick Links

🤓 Learn more about MiniRx on the Docs site
⭐ MiniRx on GitHub
🚀 See it in action on StackBlitz

The MiniRx DNA

NgRx

MiniRx is inspired by NgRx, which is a well known reactive Redux Store in the Angular world. MiniRx and NgRx look similar at first sight, but there are also important differences.

What do NgRx and MiniRx have in common?

Their names sound similar: try to speak them out loudly ;)
Powered by RxJS
Both implement the Redux Pattern
State and actions are exposed as RxJS Observable

What are the main differences?

MiniRx has no Angular dependency and is framework agnostic
MiniRx has Feature Stores to manage feature state without Redux boilerplate
MiniRx is more lightweight and admittedly does not cover every crazy use case of state management

And it is these differences which explain the name "MiniRx".

Why MiniRx

NgRx and the Redux pattern are well-suited for managing state at a large scale. But almost every application contains also features which require only a simple form of state management. Then the Redux pattern with its actions and reducers quickly feels like overkill. It would be great to have a state management solution which looks and feels a lot like NgRx, but it has to support simple state management too: Scalable state management. It was time to create MiniRx Store:

Bypass Redux boilerplate with Feature Stores

MiniRx uses the Redux pattern to make state management explicit and predictable. The Redux pattern is very powerful, but it comes with some boilerplate code (mostly actions, reducers, dispatching actions). MiniRx allows us to bypass the Redux boilerplate for simple feature states: With Feature Stores we can manage feature state directly without actions and reducer (simply use setState to update the feature state).

State Management which scales

For simple features we can use Feature Stores. And Feature Stores can be quite powerful actually: You can use memoized selectors (if you want to), you can create effects for API calls (if you want to). MiniRx scales nicely with your needs.
And you can always fall back to the Redux API in case that you have to manage huge and complex state.

Framework agnostic

NgRx is a great reactive Store, but it currently only works in Angular. There are also other frontend frameworks like Svelte which embrace reactivity. It would be cool to do NgRx-style state management in Svelte!
With MiniRx you can use whatever framework you want: you can build a framework-agnostic state management layer for Angular today and move it to Svelte (or any other frontend framework) tomorrow.

MiniRx Key Concepts

The store is a single object which holds the global application state. It is the "single source of truth"
State has a flat hierarchy and is divided into "feature states" (also called "slices" in Redux world)
For each "feature state" we can decide to use the Redux API with actions and a reducer or the Feature Store API with setState
State is exposed as RxJS Observable (The Store exposes the global state, while a Feature Store exposes a specific feature state).
State is read-only (immutable) and can only be changed by dispatching actions (Redux API) or by using setState (Feature Store API)

That was a long introduction! Let's dive into some code to see MiniRx in action...

Basic Tutorial

Store (Redux API)

MiniRx supports the classic Redux API with registering reducers and dispatching actions.
Observable state can be selected with memoized selectors.

import {
  Action,
  Store,
  configureStore,
  createFeatureSelector,
  createSelector
} from 'mini-rx-store';
import { Observable } from 'rxjs';

// 1.) State interface
interface CounterState {
  count: number;
}

// 2.) Initial state
const counterInitialState: CounterState = {
  count: 1
};

// 3.) Reducer
function counterReducer(
  state: CounterState = counterInitialState,
  action: Action
): CounterState {
  switch (action.type) {
    case 'inc':
      return {
        ...state,
        count: state.count + 1
      };
    default:
      return state;
  }
}

// 4.) Get hold of the store instance and register root reducers
const store: Store = configureStore({
  reducers: {
    counter: counterReducer
  }
});

// 5.) Create memoized selectors
const getCounterFeatureState = createFeatureSelector<CounterState>('counter');
const getCount = createSelector(
  getCounterFeatureState,
  state => state.count
);

// 6.) Select state as RxJS Observable
const count$: Observable<number> = store.select(getCount);
count$.subscribe(count => console.log('count:', count));

// 7.) Dispatch an action
store.dispatch({ type: 'inc' });

// OUTPUT: count: 1
// OUTPUT: count: 2

Feature Store API

Feature Stores allow us to manage feature state without actions and reducers.
The API of a Feature Store is optimised to select and update a feature state directly with a minimum of boilerplate.

import { FeatureStore } from 'mini-rx-store';
import { Observable } from 'rxjs';

// 1.) State interface
interface CounterState {
  count: number;
}

// 2.) Initial state
const counterInitialState: CounterState = {
  count: 11
};

export class CounterFeatureStore extends FeatureStore<CounterState> {
  // Select state as RxJS Observable
  count$: Observable<number> = this.select(state => state.count);

  constructor() {
    super('counterFs', counterInitialState);
  }

  // Update state with `setState`
  inc() {
    this.setState(state => ({ ...state, count: state.count + 1 }));
  }
}

Use the "counterFs" feature store like this:

import { CounterFeatureStore } from "./counter-feature-store";

const counterFs = new CounterFeatureStore();
counterFs.count$.subscribe(count => console.log('count:', count));
counterFs.inc();

// OUTPUT: count: 11
// OUTPUT: count: 12

The state of a Feature Store becomes part of the global state

Every new Feature Store will show up in the global state with the corresponding feature key (e.g. "counterFs"):

store.select(state => state).subscribe(console.log);

//OUTPUT: {"counter":{"count":2},"counterFs":{"count":12}}

Notes

Demo

🚀 See MiniRx Store in action on StackBlitz

The Demo uses both the Redux API and the Feature Stores:

Todos: Feature Store
Products and Cart: Redux
User: Feature Store

More MiniRx Examples:

These popular Angular demo applications show the power of MiniRx:

Angular Tetris with MiniRx
Angular Jira Clone using MiniRx
Coming soon: Angular Spotify using MiniRx

Documentation

Check out the docs for the full MiniRx API.

Show Your Support

If you like MiniRx: Give it a ⭐ on GitHub

References

These projects, articles and courses helped and inspired me to create MiniRx:

Simple yet powerful state management in Angular with RxJS

Florian Spier — Fri, 04 Sep 2020 11:22:41 +0000

TLDR Let’s create our own state management Class with just RxJS/BehaviorSubject (inspired by some well known state management libs).

Manage state with RxJS BehaviorSubject

There are several great state management libraries out there to manage state in Angular: E.g. NgRx, Akita or NgXs. They all have one thing in common: They are based on RxJS Observables and the state is stored in a special kind of Observable: The BehaviorSubject.

Why RxJS Observables?

Observables are first class citizens in Angular. Many of the core functionalities of Angular have a RxJS implementation (e.g. HttpClient, Forms, Router and more). Managing state with Observables integrates nicely with the rest of the Angular ecosystem.
With Observables it is easy to inform Components about state changes. Components can subscribe to Observables which hold the state. These "State" Observables emit a new value when state changes.

What is special about BehaviorSubject?

A BehaviorSubject emits its last emitted value to new/late subscribers
It has an initial value
Its current value can be accessed via the getValue method
A new value can be emitted using the next method
A BehaviorSubject is multicast: Internally it holds a list of all subscribers. All subscribers share the same Observable execution. When the BehaviorSubject emits a new value then the exact same value is pushed to all subscribers.

Our own state management with BehaviorSubject

So if all the big state management libs are using RxJS BehaviorSubject and Angular comes with RxJS out of the box... Can we create our own state management with just Angular Services and BehaviorSubject?

Let's create a simple yet powerful state management Class which can be extended by Angular services.

The key goals are:

Be able to define a state interface and set initial state
Straight forward API to update state and select state: setState, select
Selected state should be returned as an Observable. The Observable emits when selected state changes.
Be able to use ChangeDetectionStrategy.OnPush in our Components for better performance (read more on OnPush here: "A Comprehensive Guide to Angular onPush Change Detection Strategy").

The solution:

import { BehaviorSubject, Observable } from 'rxjs';
import { distinctUntilChanged, map } from 'rxjs/operators';

export class StateService<T> {
  private state$: BehaviorSubject<T>;
  protected get state(): T {
    return this.state$.getValue();
  }

  constructor(initialState: T) {
    this.state$ = new BehaviorSubject<T>(initialState);
  }

  protected select<K>(mapFn: (state: T) => K): Observable<K> {
    return this.state$.asObservable().pipe(
      map((state: T) => mapFn(state)),
      distinctUntilChanged()
    );
  }

  protected setState(newState: Partial<T>) {
    this.state$.next({
      ...this.state,
      ...newState,
    });
  }
}

Let’s have a closer look at the code above:

The StateService expects a generic type T representing the state interface. This type is passed when extending the StateService.
get state() returns the current state snapshot
The constructor takes an initial state and initializes the BehaviorSubject.
select takes a callback function. That function is called when state$ emits a new state. Within RxJS map the callback function will return a piece of state. distinctUntilChanged will skip emissions until the selected piece of state holds a new value/object reference. this.state$.asObservable() makes sure that the select method returns an Observable (and not an AnonymousSubject).
setState accepts a Partial Type. This allows us to be lazy and pass only some properties of a bigger state interface. Inside the state$.next method the partial state is merged with the full state object. Finally the BehaviorSubject this.state$ will emit a brand new state object.

Usage

Angular Services which have to manage some state can simply extend the StateService to select and update state.

There is only one thing in the world to manage: TODOS! :) Let’s create a TodosStateService.

interface TodoState {
  todos: Todo[];
  selectedTodoId: number;
}

const initialState: TodoState = {
  todos: [],
  selectedTodoId: undefined
};

@Injectable({
  providedIn: 'root'
})
export class TodosStateService extends StateService<TodoState>{
  todos$: Observable<Todo[]> = this.select(state => state.todos);

  selectedTodo$: Observable<Todo> = this.select((state) => {
    return state.todos.find((item) => item.id === state.selectedTodoId);
  });

  constructor() {
    super(initialState);
  }

  addTodo(todo: Todo) {
    this.setState({todos: [...this.state.todos, todo]})
  }

  selectTodo(todo: Todo) {
    this.setState({ selectedTodoId: todo.id });
  }
}

Let’s go through the TodosStateService Code:

The TodosStateService extends StateService and passes the state interface TodoState
The constructor needs to call super() and pass the initial state
The public Observables todos$ and selectedTodo$ expose the corresponding state data to interested consumers like components or other services
The public methods addTodo and selectTodo expose a public API to update state.

Interaction with Components and Backend API

Let’s see how we can integrate our TodosStateService with Angular Components and a Backend API:

Components call public methods of the TodosStateService to update state
Components interested in state simply subscribe to the corresponding public Observables which are exposed by the TodosStateService.
API calls are closely related to state. Quite often an API response will directly update the state. Therefore API calls are triggered by the TodosStateService. Once an API call has completed the state can be updated straight away using setState

Demo

See a full blown TODOs App using the TodosStateService:
Stackblitz - Angular State Manager

Notes

Immutable Data

To benefit from ChangeDetectionStrategy.OnPush in our components we have to make sure to NOT mutate the state.
It is our responsibility to always pass a new object to the setState method. If we want to update a nested property which holds an object/array, then we have to assign a new object/array as well.

See the complete TodosStateService (on Stackblitz) for more examples of immutable state updates.

FYI
There are libs which can help you to keep the state data immutable:
Immer
ImmutableJS

Template Driven Forms with two-way data binding

Regarding immutable data... We have to be careful when pushing state into a Template Driven Form where the Form inputs are using [(ngModel)]. When the user changes a Form input value then the state object will be mutated directly...
But we wanted to stay immutable and change state only explicitly using setState. Therefore it is a better alternative to use Reactive Forms. If it has to be Template Driven Forms then there is still a nice compromise: one-way data binding [ngModel]. Another option is to (deeply) clone the form data... In that case you can still use [(ngModel)].

`async` pipe for Subscriptions

In most cases components should subscribe to the "State" Observables using the async pipe in the template. The async pipe subscribes for us and will handle unsubscribing automatically when the component is destroyed.

There is one more benefit of the async pipe:
When components use the OnPush Change Detection Strategy they will update their View only in these cases automatically:

if an @Input receives a new value/object reference
if a DOM event is triggered from the component or one of its children

There are situations where the component has neither a DOM event nor an @Input that changes. If that component subscribed to state changes inside the component Class, then the Angular Change Detection will not know that the View needs to be updated once the observed state emits.

You might fix it by using ChangeDetectorRef.markForCheck(). It tells the ChangeDetector to check for state changes anyway (in the current or next Change Detection Cycle) and update the View if necessary.

@Component({
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class TodoShellComponent {
  todos: Todo[];

  constructor(
    private todosState: TodosStateService,
    private cdr: ChangeDetectorRef
  ) {
    this.todosState.todos$.subscribe(todos => {
      this.todos = todos;
      this.cdr.markForCheck(); // Fix View not updating
    });
  }
}

But we can also use the async pipe in the template instead. It is calling ChangeDetectorRef.markForCheck for us. See here in the Angular Source: async_pipe

Much shorter and prettier:

<todo-list [todos]="todos$ | async"></todo-list>

The async pipe does a lot. Subscribe, unsubscribe, markForCheck. Let's use it where possible.

See the async pipe in action in the Demo: todo-shell.component.html

`select` callbacks are called often

We should be aware of the fact that a callback passed to the select method needs to be executed on every call to setState.
Therefore the select callback should not contain heavy calculations.

Multicasting is gone

If there are many subscribers to an Observable which is returned by the select method then we see something interesting: The Multicasting of BehaviorSubject is gone... The callback function passed to the select method is called multiple times when state changes. The Observable is executed per subscriber.
This is because we converted the BehaviorSubject to an Observable using this.state$.asObservable(). Observables do not multicast.

Luckily RxJS provides an (multicasting) operator to make an Observable multicast: shareReplay.

I would suggest to use the shareReplay operator only where it's needed. Let's assume there are multiple subscribers to the todos$ Observable. In that case we could make it multicast like this:

todos$: Observable<Todo[]> = this.select(state => state.todos).pipe(
    shareReplay({refCount: true, bufferSize: 1})
);

It is important to use refCount: true to avoid memory leaks. bufferSize: 1 will make sure that late subscribers still get the last emitted value.

Read more about multicasting operators here: The magic of RXJS sharing operators and their differences

Facade Pattern

There is one more nice thing. The state management service promotes the facade pattern: select and setState are protected functions. Therefore they can only be called inside the TodosStateService. This helps to keep components lean and clean, since they will not be able to use the setState/select methods directly (e.g. on a injected TodosStateService). State implementation details stay inside the TodosStateService.
The facade pattern makes it easy to refactor the TodosStateService to another state management solution (e.g. NgRx) - if you ever want to :)

Thanks

Special thanks for reviewing this blog post:

Articles which inspired me:

Simple state management in Angular with only Services and RxJS by Aslan Vatsaev
Very similar approach: Creating A Simple setState() Store Using An RxJS BehaviorSubject In Angular 6.1.10 by Ben Nadel

MiniRx

My experience with reactive state management made it into this very cool library: MiniRx Store.
You can easily refactor the StateService from this article to MiniRx Feature Store. MiniRx Feature Store also supports setState and select, but you get extra goodies like Redux DevTools support, undo, enforced immutability, effects, memoized selectors and much more.

🤓 Learn more about MiniRx on the Docs site
⭐ MiniRx on GitHub
🚀 Angular Demo