\n(\ud83d\udd00 Branches:<\/strong>
arc-*<\/code>)<\/p>\nOption 1: Signals in Component<\/h2>\n
\ud83d\udd00 Branch: arc-simple<\/code><\/p>\nA straightforward approach is to use Signals in your components directly. Each property you want to data bind becomes a Signal:<\/p>\n
@Component({ ... })\nexport class FlightSearchComponent {\n\n private flightService = inject(FlightService);\n\n from = signal('Hamburg');\n to = signal('Graz');\n flights = signal<Flight[]>([]);\n\n async search() {\n if (!this.from() || !this.to()) return;\n\n const flights = await this.flightService.findPromise(this.from(), this.to());\n this.flights.set(flights);\n }\n\n [...]\n\n}<\/code><\/pre>\nThen, you can directly bind these signals in the template:<\/p>\n
<input [ngModel]="from()" (ngModelChange)="from.set($event)" name="from" \/>\n\n<input [ngModel]="to()" (ngModelChange)="to.set($event)" name="to" \/>\n\n<button (click)="search()">Search<\/button>\n\n<div class="row">\n <div *ngFor="let f of flights()">\n <app-flight-card [item]="f" \/>\n <\/div>\n<\/div><\/code><\/pre>\nAs of writing this, ngModel<\/code> and other parts of the FormModule<\/code> don't support two-way bindings for Signals. The Angular team will take care of a revision of forms support soon. For this reason, the previous example implements two-way binding manually by explicitly setting up a property binding for ngModel<\/code> and an event binding for ngModelChange<\/code>.<\/p>\nIn a traditional component, binding a Signal in a template is similar to binding an Observable with the async<\/code> pipe. Hence, we can also turn on OnPush<\/code>:<\/p>\n\/\/ Let's switch on OnPush for\n\/\/ FlightCardComponent and FlightSearchComponent\n@Component({\n [...]\n changeDetection: ChangeDetectionStrategy.OnPush,\n})\nexport class [...] {\n [...]\n}<\/code><\/pre>\nAngular checks OnPush<\/code> components when the async<\/code> pipe provides a new value. Since Angular 16, the same is the case when a bound Signal is updated. Assigning a new value to the flights<\/code> Signal makes Angular update the FlightSearchComponent<\/code>.<\/p>\nHowever, this is only one side of the coin: Angular also has to find out which child components need to be updated. It checks the values bound to the child components' properties. Only the object reference is checked when binding complex data types like objects or arrays. This is why Observables are usually used together with immutable data structures (Immutables). Instead of mutating such objects, a new object with the changed values is created.<\/p>\n
If we just wanted to delay the first flight, the source code would look like as follows:<\/p>\n
delay(): void {\n const flights = this.flights();\n const flight = flights[0];\n\n const date = addMinutes(flight.date, 15);\n\n this.flights.update(flights => ([\n { ...flight, date },\n ...flights.slice(1)\n ]));\n}<\/code><\/pre>\nThe following code would not work when using OnPush<\/code> as it is not changing the object reference of the respective flight:<\/p>\n\/\/ Alternative w\/ Mutables:\n\/\/ Won't work with OnPush\nthis.flights.mutate((flights) => {\n flights[0].date = date;\n});<\/code><\/pre>\nInstead of using Signals with Immutables, one could also use nested Signals, e. g. a Signal with an Array containing Signals with flights. However, such structures needed to be created by hand; hence I assume that sticking with Immutables is easier for now. The following section explains that switching to nested Signals can speed up the data binding once we get the envisioned Signal Components.<\/p>\n
Excursus: Change Detection in Angular -- Today and Tomorrow<\/h2>\n
When not using OnPush<\/code>, Angular checks all components for updates after event handlers ran. Components in OnPush<\/code> mode, however, are only checked if they have been marked as dirty. This happens, for instance, if an Observable bound with async<\/code> or a bound Signal emits a new value. <\/p>\nWhen (the object reference of) a bound input changes, the component is marked too. Together with the component, all ancestors in the component tree are marked, as Angular's change detection traverses the component tree top\/down. Interestingly, marked components are always fully checked for changes, even if only an update affects a part. <\/p>\n
Signal Components, envisioned for future Angular versions, will provide a more fine-grained behavior: Only changed parts of components will be checked. These parts will be embedded views defined by structural directives like ngFor<\/code> or <\/em>ngIf<\/code>. Also, ancestors of Signal Components won't automatically be checked.<\/p>\nIn this case, having nested signals will provide an advantage over Immutables, as they allow our application to directly notify Angular about the component parts that need to be updated. <\/p>\n
Option 2: Move Signals to a Service<\/h2>\n
\ud83d\udd00 Branch: arc-facade2<\/code><\/p>\nSignals are not limited to be used in components. By design, they can be used everywhere. Hence, we can also move them into a service:<\/p>\n
@Injectable({ providedIn: 'root' })\nexport class FlightBookingFacade {\n private flightService = inject(FlightService);\n\n readonly flights = signal<Flight[]>([]);\n readonly from = signal('Hamburg');\n readonly to = signal('Graz');\n\n async load(): Promise<void> {\n [...]\n }\n\n delay(): void {\n [...]\n }\n}<\/code><\/pre>\nSuch services can be used by several components and hence allow for sharing state. But even if only used by one component, they provide some added value: One can relieve the component from taking care of state management, and the service can preserve the state when the component is destroyed and re-created, e.g., when leaving a route and returning to it.<\/p>\n
The component can use such a service as follows:<\/p>\n
@Component({ ... })\nexport class FlightSearchComponent {\n\n private facade = inject(FlightBookingFacade);\n\n from = this.facade.from;\n to = this.facade.to;\n flights = this.facade.flights;\n\n async search() {\n this.facade.load();\n }\n\n delay(): void {\n this.facade.delay();\n }\n\n}<\/code><\/pre>\nOption 3: Information Hiding With Services<\/h2>\n
\ud83d\udd00 Branch: arc-facade3<\/code><\/p>\nIf several components use a service, it might be a good idea to make the exposed Signals read\/only. This forces all the components to update the state in a well-defined way, e.g., by calling service methods intended for the update in question.<\/p>\n
For creating a read\/only Signal out of a writable one, the method asReadonly<\/code> can be used:<\/p>\n@Injectable({ providedIn: 'root' })\nexport class FlightBookingFacade {\n private flightService = inject(FlightService);\n\n private _flights = signal<Flight[]>([]);\n readonly flights = this._flights.asReadonly();\n\n private _from = signal('Hamburg');\n readonly from = this._from.asReadonly();\n\n private _to = signal('Graz');\n readonly to = this._to.asReadonly();\n\n updateCriteria(from: string, to: string): void {\n this._from.set(from);\n this._to.set(to);\n }\n\n [...]\n}<\/code><\/pre>\nThis style is also known from RxJS where writable Subjects<\/code> are converted to read\/only Observables<\/code>. Unfortunately, this code is quite lengthy. The following section provides a solution.<\/p>\nOption 3a: Service with State-Signal<\/h2>\n
\ud83d\udd00 Branch: arc-facade3a<\/code><\/p>\nTo streamline option 3 a bit, we could introduce a private writable state<\/code> Signal and derive the individual read\/only Signals from it via computed<\/code>:<\/p>\nimport { equal, patchSignal } from '..\/..\/..\/shared\/util-common';\n\n[...]\n\n@Injectable({ providedIn: 'root' })\nexport class FlightBookingFacade {\n private flightService = inject(FlightService);\n\n private state = signal({\n from: 'Hamburg',\n to: 'Graz',\n flights: [] as Flight[],\n basket: {} as Record<number, boolean>,\n });\n\n readonly flights = computed(() => this.state().flights, { equal });\n readonly from = computed(() => this.state().from, { equal });\n readonly to = computed(() => this.state().to, { equal });\n readonly basket = computed(() => this.state().basket, { equal });\n\n updateCriteria(from: string, to: string): void {\n patchSignal(this.state, { from, to });\n }\n\n [...]\n\n}<\/code><\/pre>\nThis already looks like the usage of a lightweight store like the NGRX Component Store. The used helper function patchState<\/code> does indeed borrow one of the Component Store's ideas:<\/p>\nexport function patchSignal<T>(signal: WritableSignal<T>, partialState: Partial<T>) {\n signal.update((state) => ({\n ...state,\n ...partialState,\n }));\n}<\/code><\/pre>\nOf course, store libraries provide additional features, and as of writing this, an NGRX Signal Store is in the works. I'm going to update this article once the signal store is available.<\/p>\n
The helper function equal<\/code> tells the Signal, when its value is considered to be changed. As we are going with Immutable state, it's just about comparing object references and primitive values. For both, the ===<\/code> operator is used:<\/p>\nexport function equal<T>(a: T, b: T): boolean {\n return a === b;\n}<\/code><\/pre>\nExcursus: The equal Function<\/h2>\n
Each Signal has an equal<\/code> function defining when its value is considered to be changed. This function is called after updating the Signal. Only if it returns false<\/code>, the consumers are notified. At least this is how it can be seen on the logical level. On the implementation level it's a bit more complicated.<\/p>\nConsumers are computed Signals and effects. Angular's change detection also uses the latter to track the bound Signals values.<\/p>\n
The default implementation we get when not explicitly setting this function works as follows:<\/p>\n
\n- For objects (including arrays),
false<\/code> is always returned.<\/li>\n- Otherwise (e. g. for strings, numbers, booleans), the result of
oldValue === newValue<\/code> is returned.<\/li>\n<\/ul>\nThe first bullet point might be surprising. The reason is that the Signal cannot know how to compare our complex structures, and always performing a deep comparison seems too costly. Just returning false<\/code> makes it work with mutable data too. Obviously, this also leads to more notifications as actually needed. The comparison described in the second bullet point ensures that consumers are not notified if a signal is updated with the same primitive value.<\/p>\nAs we use immutable state in the examples shown here, our custom equal<\/code> function can always compare the former value with the current value.<\/p>\nUnfortunately, there is a small caveat when using Immutables: When a part of the immutable state is changed, the whole state object must also be changed. You can see this in the discussed patchSignal<\/code> function: It always returns a new state object, the former state, but also the new partial state is spread into. Consequently, all computed<\/code> Signals are recomputed. As our computations are just projections (e. g. from state<\/code> to state().flights<\/code>), this shouldn't be too costly. <\/p>\nHowever, it would be costly if Angular marked the components as dirty after each re-computation. The registered equal<\/code> function prevents this: It returns true<\/code> if the object reference did not change. As a result, the Signal does not notify Angular, and the component is not marked as dirty.<\/p>\nAs of writing this, it seems like all the existing store implementations adapted for Signals recently have this behavior. This isn't that surprising because they internally use immutable data structures. According to a first RFC document, the envisioned NGRX Signal Store will internally have separate Signals for each top-level state property. This reduces the issue at hand. <\/p>\n
Option 3b: Adding a Simple Store<\/h2>\n
\ud83d\udd00 Branch: arc-facade3d<\/code><\/p>\nWhile the previous option was easy to read and maintain, it has two drawbacks: One has to remember to use an equal function for immutables, and there is just one signal for the whole state. Ideally, a Signal just contains elements that usually change together. A simple generic solution would at least create one Signal for each property on root level. Both can be automated with a simple hand-made store:<\/p>\n
@Injectable({ providedIn: 'root' })\nexport class FlightBookingFacade {\n private flightService = inject(FlightService);\n\n private state = createStore({\n from: 'Hamburg',\n to: 'Graz',\n flights: [] as Flight[],\n basket: {} as Record<number, boolean>,\n });\n\n \/\/ Option 1: fetch root signals as readonly\n flights = this.state.select(s => s.flights());\n from = this.state.select(s => s.from());\n to = this.state.select(s => s.to())\n basket = this.state.select(s => s.basket());\n\n \/\/ Option 2: use selectors for computing a view model\n selected = this.state.select(s => s.flights().filter(f => s.basket()[f.id]));\n\n updateCriteria(from: string, to: string): void {\n this.state.update('from', from);\n this.state.update('to', to);\n }\n\n [...]\n}<\/code><\/pre>\nInternally, the store maintains a separate signal for each property at root level, and the select<\/code>`` method is just a wrapper around computed that passes a respective equal function.<\/p>\nThe store<\/a> itself can be written with about 60 lines of code. Please find it here<\/a>.<\/p>\nOption 4: Using a Store and the Redux Pattern<\/h2>\n
\ud83d\udd00 Branch: arc-ngrx<\/code><\/p>\nWe could also use a store library as an alternative to manage the state in a service by hand. Choosing one that follows the Redux pattern ensures the state is only modified in a well-defined way. The most popular Redux implementation for Angular is NGRX. Fortunately, it has been supporting Signals since version 16.<\/p>\n
The following example shows how its new selectSignal<\/code> method allows retrieving a part of the immutable state tree as a Signal<\/code>:<\/p>\n@Component({ ... })\nexport class FlightSearchComponent {\n private store = inject(Store);\n\n criteria = this.store.selectSignal(ticketingFeature.selectCriteria);\n flights = this.store.selectSignal(ticketingFeature.selectFlights);\n\n updateCriteria(from: string, to: string): void {\n this.store.dispatch(ticketingActions.updateCriteria({ from, to }));\n }\n\n search(): void {\n this.store.dispatch(\n ticketingActions.loadFlights({\n from: this.criteria().from,\n to: this.criteria().to,\n })\n );\n }\n\n delay(): void {\n const flights = this.flights();\n const id = flights[0].id;\n this.store.dispatch(ticketingActions.delayFlight({ id }));\n }\n\n}<\/code><\/pre>\nThe complete usage of NGRX, including the source code defining the state, actions, reducers, and effects, can be found in the \ud83d\udd00 branch arc-ngrx<\/code>.<\/p>\nOption 5: Hiding the Store Behind a Facade<\/h2>\n
\ud83d\udd00 Branch: arc-ngrx-facade<\/code><\/p>\nSometimes, hiding the used store implementation behind a service can be beneficial. Such a so-called facade provides a domain-specific interface and allows to introduce the store gradually or to use it selectively:<\/p>\n
@Injectable({ providedIn: 'root' })\nexport class FlightBookingFacade {\n private store = inject(Store);\n\n criteria = this.store.selectSignal(ticketingFeature.selectCriteria);\n flights = this.store.selectSignal(ticketingFeature.selectFlights);\n\n updateCriteria(from: string, to: string): void {\n this.store.dispatch(ticketingActions.updateCriteria({ from, to }));\n }\n\n load(): void {\n if (!this.criteria().from || !this.criteria().to) return;\n this.store.dispatch(\n ticketingActions.loadFlights({\n from: this.criteria().from,\n to: this.criteria().to,\n })\n );\n }\n\n delay(): void {\n const flights = this.flights();\n const id = flights[0].id;\n this.store.dispatch(ticketingActions.delayFlight({ id }));\n }\n}<\/code><\/pre>\nIf you know from the beginning that you will go all-in with your store, wrapping it in such a facade might be overhead.<\/p>\n
Conclusion<\/h2>\n
Signals can be defined directly within components but also within a service. In the latter case, public read\/only Signals can be derived from a private writable Signal. By providing methods for manipulating the state, one can ensure that the state is only modified in a well-defined way. Instead of hand-writing such a service, existing store libraries adapted for Signals can be used. A famous example is NGRX.<\/p>\n
Also, it will be interesting to see how store libraries will evolve to better support Signals and the upcoming Signal Components. A promising development is the envisioned NGRX Signal Store.<\/p>\n
What's next? More on Architecture!<\/h2>\n
Please find more information on enterprise-scale Angular architectures in our free eBook (5th edition, 12 chapters): <\/p>\n
\n- According to which criteria can we subdivide a huge application into sub-domains?<\/li>\n
- How can we make sure, the solution is maintainable for years or even decades?<\/li>\n
- Which options from Micro Frontends are provided by Module Federation?<\/li>\n<\/ul>\n
![\"free](\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2022\/12\/cover-5th-small.png\")
<\/a><\/p>\n