{"id":25344,"date":"2024-04-03T21:21:16","date_gmt":"2024-04-03T19:21:16","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=25344"},"modified":"2025-06-04T16:57:11","modified_gmt":"2025-06-04T14:57:11","slug":"successful-with-signals-in-angular-3-effective-rules-for-your-architecture","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/successful-with-signals-in-angular-3-effective-rules-for-your-architecture\/","title":{"rendered":"Successful with Signals in Angular – 3 Effective Rules for Your Architecture"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 3 of 9 in the series “Signals”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Signals in Angular: Building Blocks<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. Component Communication with Signals: Inputs, Two-Way Bindings, and Content\/ View Queries<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Successful with Signals in Angular – 3 Effective Rules for Your Architecture<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Skillfully Using Signals in Angular – Selected Hints for Professional Use<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. When (Not) to use Effects in Angular — and what to do instead<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Asynchronous Data Flow with Angular’s new Resource API<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Streaming Resources in Angular – Details and Semantics<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  8. Streaming Resources for a Chat with Web Sockets: Messages in a Glitch-Free World<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  9. Angular’s new httpResource<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    It is undisputed that Signals will shape the future of Angular. At first glance, they seem very easy to use: The setters take new values, the getters deliver the current values and the templates as well as Effects are notified about changes.<\/p>\n

    Now you might be tempted to treat Signals like normal variables. This works in principle and can be a practical option when migrating existing code. However, in this case, the advantages of Signals and reactive systems only result to a limited extent. There are also some pitfalls and the code is not as straightforward and hence not as maintainable as it could be.<\/p>\n

    In order to prevent such situations, I would like to use this article to give you three simple rules of thumb that allow Signals to be used as idiomatically as possible. <\/p>\n

    \ud83d\udcc1 Source Code<\/a> (see different branches!)<\/p>\n

    \nBig thanks to Angular's Alex Rickabaugh<\/a> for a great discussion that led to the idea for this article and for providing feedback.\n<\/p><\/blockquote>\n

    Initial Example With Some Room for Improvement<\/h2>\n

    I would like to discuss the three promised rules using a simple Angular application:<\/p>\n

    \"Example<\/p>\n

    The first implementation considered is not reactive and also offers some room for improvement:<\/p>\n

    @Component([\u2026])\nexport class DessertsComponent implements OnInit {\n  #dessertService = inject(DessertService);\n  #ratingService = inject(RatingService);\n  [\u2026]\n\n  originalName = '';\n  englishName = '';\n  loading = false;\n\n  desserts: Dessert[] = [];\n\n  ngOnInit(): void {\n    this.search();\n  }\n\n  search(): void {\n    const filter: DessertFilter = {\n      originalName: this.originalName,\n      englishName: this.englishName,\n    };\n\n    this.loading = true;\n\n    this.#dessertService.find(filter).subscribe({\n      next: (desserts) => {\n        this.desserts = desserts;\n        this.loading = false;\n      },\n      error: (error) => { [\u2026] },\n    });\n  }\n\n  toRated(desserts: Dessert[], ratings: DessertIdToRatingMap): Dessert[] {\n    return desserts.map((d) =>\n      ratings[d.id] ? { ...d, rating: ratings[d.id] } : d,\n    );\n  }\n\n  loadRatings(): void {\n    this.loading = true;\n\n    this.#ratingService.loadExpertRatings().subscribe({\n      next: (ratings) => {\n        const rated = this.toRated(this.desserts, ratings);\n        this.desserts = rated;\n        this.loading = false;\n      },\n      error: (error) => { [\u2026] },\n    });\n  }\n  [\u2026]\n}<\/code><\/pre>\n
    Since the properties to be bound are neither Observables nor Signals, the strategy OnPush<\/code> cannot be used for improving the data binding performance. Upon closer inspection, we also notice that the loadRatings<\/code> method updates the desserts<\/code> array, even though its actual task -- loading ratings -- has nothing to do with it.<\/p>\n
    Additionally, developers must remember that after any changes to the ratings, the desserts<\/code> array must also be modified. This is exactly what can lead to hard-to-maintain code and hidden bugs -- especially when both desserts<\/code> and ratings<\/code> change at different points. Things become even more complex when additional data structures have to be taken into account in these calculations. The first rule of thumb presented here solves this issue.<\/p>\n
    Rule 1: Derive State Synchronously Whereever Possible<\/h2>\n
    The previously mentioned disadvantages can be compensated for with Signals. Since the introduction of Signals makes the component reactive, OnPush<\/code> can now be activated. In addition, the component can derive its state from the individual Signals using computed<\/code> synchronously:<\/p>\n
    @Component({\n  [\u2026],\n  changeDetection: ChangeDetectionStrategy.OnPush,\n})\nexport class DessertsComponent implements OnInit {\n  #dessertService = inject(DessertService);\n  #ratingService = inject(RatingService);\n\n  originalName = signal('');\n  englishName = signal('');\n  loading = signal(false);\n\n  desserts = signal<Dessert[]>([]);\n  ratings = signal<DessertIdToRatingMap>({});\n  ratedDesserts = computed(() => this.toRated(this.desserts(), this.ratings()));\n\n  [\u2026]\n\n  loadRatings(): void {\n    this.loading.set(true);\n\n    this.#ratingService.loadExpertRatings().subscribe({\n      next: (ratings) => {\n        this.ratings.set(ratings);\n        this.loading.set(false);\n      },\n      error: (error) => { [\u2026] }\n  });\n\n  [\u2026]\n}<\/code><\/pre>\n
    This makes the code a lot more straightforward: The loadRatings<\/code> method simply loads the ratings and places them in a signal. The computed<\/code> Signal ratedDesserts<\/code> takes care of mergining desserts<\/code> and ratings<\/code>. No matter when and where the application updates desserts<\/code> or ratings<\/code>, ratedDesserts<\/code> is always up to date.<\/p>\n
    When applying this pattern, it is important to note that computed<\/code> can only derive state in a synchronous manner. For an asynchronous derivation, Angular provides the Resource API<\/a>.<\/p>\n
    More: Angular Architecture Workshop (online, interactive, advanced)<\/h2>\n
    Become an expert for enterprise-scale and maintainable Angular applications with our Angular Architecture workshop!<\/a>\"\"<\/p>\n
    All Details (English Workshop)<\/a> | All Details (German Workshop)<\/a>
    \n<\/p>\n
    Rule 2: Avoid Effects for Propagating State<\/h2>\n
    Effects are the right choice when presenting values cannot be achieved via data binding. However, they bring some pitfalls when used for propagating change. In the next sections, I elaborate on this.<\/p>\n
    Proper Usage of Effects<\/h3>\n
    In most cases, Signals are bound in the template. However, it happens that the desired form of output cannot be achieved via data binding. An example of this is outputting a Signal to the console for debugging purposes. Another example are toasts that can be activated via services and are intended to present the value of a Signal. For these cases, Angular provides Effects:<\/p>\n
    [\u2026]\nconstructor() {\n  effect(() => {\n    console.log('originalName', this.originalName());\n    console.log('englishName', this.englishName());\n  });\n\n  effect(() => {\n    this.#toastService.show(this.desserts().length + ' desserts loaded!');\n  });\n}\n[\u2026]<\/code><\/pre>\n
    Signals are Glitch-free<\/h3>\n
    When writing code like in the previous section, we need to be aware that Signals are glitch-free. That means that if you change a signal several times in a row (within a stack frame), only the last change will be seen by the consumer, e.g. the effect:<\/p>\n
    @Component([...])\nexport class AboutComponent {\n\n  constructor() {\n    const signal1 = signal('A');\n    const signal2 = signal('B');\n\n    effect(() => {\n      console.log('signal1', signal1());\n      console.log('signal2', signal2());\n    });\n\n    signal1.set('C');\n    signal1.set('D');\n\n    signal1.set('E');\n\n    signal2.set('F');\n  }\n}<\/code><\/pre>\n
    In this case, we will only see the values E<\/code> and F<\/code> on the console. Indemediate values are skipped.<\/p>\n
    This shows that Signals are not intended for modelling events but for data we want to bind to the view. In the latter case, we just need the current value while binding intermediate values would be counterproductive. For this reasons, the effects shown in the previous section are only triggered once even if there are several changes in a row. <\/p>\n
    In cases where we want to express events, Observables are the way to go, as they don't have this glitch-free guarantee by design.<\/p>\n
    Problematic Use of Effects<\/h3>\n
    Even when using Effects, Signals are primarily used to transport the desired data into the view. In theory, however, Effects could also be used to transmit state to other Signals:<\/p>\n
    effect(() => {\n    this.originalName.set(this.englishName());\n});<\/code><\/pre>\n
    However, such approaches have several disadvantages, which is why Angular prohibits writing Signals within Effects by default:<\/p>\n
    \"Error<\/p>\n
    One of these disadvantages is that unmanageable change cascades and thus difficult-to-maintain code and cyclic dependencies can arise. Since Effects register implicitly with all Signals used, the associated problems may not even be noticeable at first glance. If you still want to use Effects for writing, you can make Angular let things slide by setting allowSignalWrites<\/code>:<\/p>\n
    \/\/ Try hard to avoid this\neffect(() => {\n    this.originalName.set(this.englishName());\n  },\n  { allowSignalWrites: true },\n);<\/code><\/pre>\n
    \nApplication code should only use allowSignalWrites<\/code> as a last resort.\n<\/p><\/blockquote>\n
    The general consensus in the community is that application code should only use allowSignalWrites<\/code> as a last resort. On the other hand, libraries like NGRX use this option internally. In this case, however, the authors of the library are responsible for its correct use, so application developers don't have to worry about it.<\/p>\n
    It is also important to note that the Effect itself registers with Signals in called methods too. For instance, the following Effect is triggered when Signals change within search<\/code>:<\/p>\n
    \/\/ Try hard to avoid this\neffect(() => {\n    this.search();\n  },\n  { allowSignalWrites: true },\n);<\/code><\/pre>\n
    This leads to a further increase in complexity. At least this problem could be alleviated with built-in features:<\/p>\n
    \/\/ Try hard to avoid this\neffect(() => {\n    const originalName = this.originalName(); \n    const englishName = this.englishName();\n    untracked(() => {\n        this.load(originalName, englishName);\n    })\n  }\n);<\/code><\/pre>\n
    The untracked<\/code> function avoids the current reactive context spilling over to the called search<\/code> method. Angular now also uses this pattern itself in selected cases<\/a>. An example of this is triggering events in sub-components so that the event handler does not run in the reactive context of the code that triggered the event. Further popular libraries that use this technique are NGRX, NGRX Signal Store or ngextensions.<\/p>\n
    Strategies for Preventing Effects With Signal Writes<\/h3>\n
    Effects that spread data via Signal writes can in many cases be prevented using the following approaches:<\/p>\n