auf seinem Blog<\/a>.
\n
<\/p>\nStatt Subscriptions, pipe() und komplexen Streams gen\u00fcgen nun wenige Zeilen mit signal(), computed() und effect(). Der Code wirkt schlanker, intuitiver und n\u00e4her am User Interface (UI).<\/p>\n
Da liegt die Idee nahe: Wenn Signals im UI \u00fcberzeugen, warum nicht auch in der Applikationslogik? Warum nicht RxJS vollst\u00e4ndig ersetzen? Ein Application Store ohne Actions, Meta-Framework und Observable: direkt, deklarativ, minimalistisch.<\/p>\n
Ein Ansatz, der im Folgenden anhand eines konkreten Fallbeispiels analysiert und kritisch hinterfragt wird. Anschlie\u00dfend wird behandelt, in welchen Kontexten sich Signals sinnvoll einsetzen lassen.<\/p>\n
Aufbau des Fallbeispiels<\/p>\n
Auf den ersten Blick besitzt dieses Beispiel einen klar strukturierten Architekturansatz. Doch der Wandel beginnt unauff\u00e4llig. RxJS bleibt zun\u00e4chst au\u00dfen vor. Das UI reagiert fl\u00fcssig, der Code bleibt \u00fcbersichtlich. Komplexe Streams, verschachtelte Operatoren oder eigenes Subscription Handling entfallen. Stattdessen kommen Signals zum Einsatz. Es liegt nahe, diese unkomplizierte Herangehensweise auch f\u00fcr die Applikationslogik zu \u00fcbernehmen. Im folgenden Beispiel \u00fcbernimmt ein ProductStore die Zustandslogik. Signals organisieren Kategorien, Filter und Produktdaten \u2013 reaktiv und direkt.<\/p>\n
@Injectable({ providedIn: ‚root‘ })
\nexport class ProductStore {
\n private allProducts = signal([]);
\n readonly selectedCategory = signal(‚B\u00fccher‘);
\n readonly onlyAvailable = signal(false);<\/p>\n
readonly productList = computed(() => {
\n return this.allProducts().filter(p =>
\n this.onlyAvailable() ? p.available : true
\n );
\n });<\/p>\n
selectCategory(category: string) {
\n this.selectedCategory.set(category);
\n }<\/p>\n
toggleAvailabilityFilter() {
\n this.onlyAvailable.set(!this.onlyAvailable());
\n }<\/p>\n
constructor(private api: ProductApiService) {
\n effect(() => {
\n const category = this.selectedCategory();
\n const onlyAvailable = this.onlyAvailable();
\n this.api.getProducts(category, onlyAvailable).then(products => {
\n this.allProducts.set(products);
\n });
\n });
\n }
\n}<\/p>\n
Die Struktur \u00fcberzeugt zun\u00e4chst durch Klarheit. Die Komponente konsumiert productList direkt, ohne eigene Logik. Der Store verwaltet den Zustand, Signals sorgen f\u00fcr die Weitergabe von \u00c4nderungen.<\/p>\n
Doch mit der n\u00e4chsten Anforderung \u00e4ndert sich das Bild: Bestimmte Produkte sollen zwar im Katalog verbleiben, aber im UI nicht mehr erscheinen. Da auch andere Systeme die bestehende API verwenden, ist eine Anpassung nicht m\u00f6glich. Stattdessen liefert das Backend eine Liste freigegebener Produkt-IDs, anhand derer das UI filtert.<\/p>\n
@Injectable({ providedIn: ‚root‘ })
\nexport class ProductStore {
\n \/\/ […]<\/p>\n
readonly backendEnabledProductIds = signal>(new Set());<\/p>\n
readonly productList = computed(() => {
\n return this.allProducts().filter(p =>
\n this.onlyAvailable() ? p.available : true
\n ).filter(p => this.backendEnabledProductIds().has(p.id));
\n });<\/p>\n
constructor(private api: ProductApiService) {
\n effect(() => {
\n const category = this.selectedCategory();
\n const onlyAvailable = this.onlyAvailable();
\n this.api.getProducts(category, onlyAvailable).then(products => {
\n this.allProducts.set(products);
\n });
\n });<\/p>\n
effect(() => {
\n this.api.getEnabledProductIds().then(ids => {
\n this.backendEnabledProductIds.set(new Set(ids));
\n });
\n });
\n }<\/p>\n
\/\/ […]
\n}<\/p>\n
Nach au\u00dfen bleibt die Architektur zun\u00e4chst unver\u00e4ndert. Die Komponente enth\u00e4lt weiterhin keine eigene Logik, Subscriptions sind nicht notwendig, und die Reaktivit\u00e4t scheint erhalten zu bleiben. Im Service jedoch nimmt die Zahl der effect()s zu, Abh\u00e4ngigkeiten werden vielf\u00e4ltiger, und die \u00dcbersichtlichkeit leidet.<\/p>\n
Nach und nach wandert Logik in verteilte effect()s, bis ihre Zust\u00e4ndigkeiten kaum noch greifbar sind. Aus einem \u00fcberschaubaren ViewModel entsteht ein Gebilde mit immer mehr impliziten Reaktionen \u2013 eine Entwicklung, die ein waches Auge f\u00fcr Architektur erfordert.<\/p>\n
Wenn reaktive Systeme entgleisen<\/p>\n
Das Setup wirkt zun\u00e4chst unspektakul\u00e4r. Die Produktliste wird \u00fcber ein computed() erstellt, gefiltert nach Verf\u00fcgbarkeit und den vom Backend freigegebenen IDs. Zwei effect()s laden die Daten.<\/p>\n
Der Code wirkt aufger\u00e4umt und l\u00e4sst sich modular erweitern. Doch der n\u00e4chste Feature-Wunsch stellt das System auf die Probe: Die Stakeholder m\u00f6chten wissen, wie oft bestimmte Kategorien angesehen werden. Die Entwicklerinnen und Entwickler entscheiden sich f\u00fcr einen naheliegenden Ansatz. Eine \u00c4nderung der Kategorie l\u00f6st ein Tracking-Event aus. Ein effect() scheint daf\u00fcr perfekt geeignet \u2013 unkompliziert und ohne erkennbare Nebenwirkungen:<\/p>\n
effect(() => {
\n const category = this.selectedCategory();
\n this.analytics.trackCategoryView(category);
\n});<\/p>\n
Schnell eingebaut, kein zus\u00e4tzlicher State, keine neue Subscription. Eine Reaktion auf das bestehende Signal, unkompliziert und ohne erkennbare Nebenwirkungen. Doch damit verl\u00e4sst der Code den Bereich kontrollierter Reaktivit\u00e4t.<\/p>\n
Der Kipppunkt<\/p>\n
Die Annahme ist klar: \u00c4ndert sich die Kategorie, wird ein Tracking ausgel\u00f6st. Was dabei leicht zu \u00fcbersehen ist: Signals reagieren nicht auf Bedeutung, sondern auf jede Mutation. Auch wenn set() denselben Wert schreibt oder zwei Komponenten nacheinander dieselbe Auswahl treffen, passiert zwar technisch etwas, semantisch aber nicht. Das Ergebnis sind doppelte Events und verzerrte Metriken, ohne dass der Code einen Hinweis darauf gibt. Alles sieht korrekt aus.<\/p>\n
Das Tracking erfolgt unmittelbar im selben Ausf\u00fchrungstakt (Tick), ohne M\u00f6glichkeit zur Entkopplung. Wenn parallel ein weiterer effect() ausgel\u00f6st wird \u2013 etwa durch ein zweites Signal \u2013, fehlt jegliche Koordination.<\/p>\n
Die Reihenfolge ist nicht vorhersehbar, und das UI kann in einen inkonsistenten Zustand geraten: Daten werden mehrfach geladen, Reaktionen \u00fcberschneiden sich, Seiteneffekte sind nicht mehr eindeutig zuzuordnen. Mit jedem zus\u00e4tzlichen effect() steigt die Zahl impliziter Wechselwirkungen. Was wie ein reagierendes System wirkt, ist l\u00e4ngst nicht mehr entscheidungsf\u00e4hig.<\/p>\n
In einem Kundenprojekt f\u00fchrte genau dieser Zustand dazu, dass ein effect() mehrfach pro Sekunde ausl\u00f6ste. Nicht wegen einer echten \u00c4nderung, sondern weil derselbe Wert mehrfach gesetzt wurde. Das UI zeigte korrekte Daten, aber das Backend war mit redundanten Anfragen \u00fcberlastet.<\/p>\n
Das Missverst\u00e4ndnis<\/p>\n
effect() wirkt wie ein deklarativer Controller: „Wenn sich X \u00e4ndert, tue Y.“ Doch in Wirklichkeit ist es ein reaktiver Spion. Er beobachtet jedes Signal, das gelesen wird, unabh\u00e4ngig von der semantischen Bedeutung. Er feuert sogar dann, wenn niemand es erwartet. Und er ist nicht koordiniert. Jeder effect() lebt in seiner eigenen Welt, ohne zentrale Regie.<\/p>\n
Was als architektonische Vereinfachung begann, endet in einer Blackbox aus Zust\u00e4nden, Reaktionen und Nebenwirkungen. Mit jedem weiteren Feature w\u00e4chst diese Komplexit\u00e4t. Es gibt keinen gro\u00dfen Knall, aber eine zuvor elegant erscheinende Struktur driftet leise auseinander.<\/p>\n
\n Dieser Link ist leider nicht mehr g\u00fcltig.\n <\/p>\n
Links zu verschenkten Artikeln werden ung\u00fcltig,
\n wenn diese \u00e4lter als 7\u00a0Tage sind oder zu oft aufgerufen wurden.\n <\/p>\n
Sie ben\u00f6tigen ein heise+ Paket, um diesen Artikel zu lesen. Jetzt eine Woche unverbindlich testen \u2013 ohne Verpflichtung!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"Mit Angular 17 hielten Signals 2023 offiziell Einzug in das Framework. Sie versprechen eine modernere, klarere Reaktivit\u00e4t: weniger…\n","protected":false},"author":2,"featured_media":312816,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[135],"tags":[89782,29,47841,30,196,89783,190,189,89784,194,191,41528,193,192],"class_list":{"0":"post-312815","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-wissenschaft-technik","8":"tag-angular","9":"tag-deutschland","10":"tag-developer","11":"tag-germany","12":"tag-it","13":"tag-javascript-framework","14":"tag-science","15":"tag-science-technology","16":"tag-softwarearchitektur","17":"tag-technik","18":"tag-technology","19":"tag-webentwicklung","20":"tag-wissenschaft","21":"tag-wissenschaft-technik"},"share_on_mastodon":{"url":"https:\/\/pubeurope.com\/@de\/114958082132754692","error":""},"_links":{"self":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts\/312815","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/comments?post=312815"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts\/312815\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/media\/312816"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/media?parent=312815"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/categories?post=312815"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/tags?post=312815"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}