{"id":24793,"date":"2024-02-12T12:05:51","date_gmt":"2024-02-12T11:05:51","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=24793"},"modified":"2024-03-07T18:27:43","modified_gmt":"2024-03-07T17:27:43","slug":"component-communication-with-signals-inputs-two-way-bindings-and-content-view-queries","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/component-communication-with-signals-inputs-two-way-bindings-and-content-view-queries\/","title":{"rendered":"Component Communication with Signals: Inputs, Two-Way Bindings, and Content\/ View Queries"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 2 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<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Successful with Signals in Angular – 3 Effective Rules for Your Architecture<\/a><\/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

    Signals will shape Angular's future. However, the Signals concept itself is just one part of the overall story. We also need a way to communicate with (sub)components via Signals. Angular 17.1 brought Input Signals, and with Angular 17.2 we've got Signal-based Two-way Bindings and support for content and view queries. To align with Input Signals, Version 17.3 provides a new output API.<\/p>\n

    In this article, I show how to use these new possibilities.<\/p>\n

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

    \n

    Big thanks to Angular's Alex Rickabaugh<\/a> for an enlightening discussion about an idiomatic usage of Signals and to my awesome colleague Michael Egger-Zikes<\/a> for providing valuable feedback.<\/p>\n<\/blockquote>\n

    Input Signals<\/h2>\n

    Inputs Signals allow us to receive data via Property Bindings in the form of Signals. For describing the usage of Signal Inputs, I'm using a simple OptionComponent<\/code> representing a -- for the sake of simplicity -- non-selectable option. Here, three of them are presented:<\/p>\n

    \"Three<\/p>\n

    Defining an Input Signal<\/h3>\n

    Input Signals are the counterpart to the traditional @Input decorator:<\/p>\n

    @Component({\n  selector: 'app-option',\n  standalone: true,\n  imports: [],\n  template: `\n    <div class="option">\n      {{ label() }}\n    <\/div>\n  `,\n  styles: [...]\n})\nexport class OptionComponent {\n  label = input.required<string>();\n}<\/code><\/pre>\n
    This input<\/code> function is picked up by the Angular Compiler, emitting source code for property bindings. Hence, we should only use it together with properties. The other communication concepts discussed here also use this technique.<\/p>\n
    Having a function instead of a decorator allows to inform TypeScript about the proper type and whether it includes undefined<\/code>. In the example shown before, label<\/code> becomes an InputSignal<string><\/code> -- an Input Signal providing a string<\/code>. An undefined<\/code> value is not possible as input.required<\/code> defines a mandatory property.<\/p>\n
    An InputSignal<\/code> is always read-only and can be used like a Signal<\/code>. The template above, for instance, requests its current value by calling the getter (label()<\/code>).<\/p>\n
    Binding to an Input Signal<\/h3>\n
    In the case of our InputSignal<string><\/code>, the caller has to pass a string<\/code>:<\/p>\n
    <app-option label="Option #1">\n<app-option [label]="myStringProperty"><\/code><\/pre>\n
    If this string comes from a Signal, we have to read it in the template:<\/p>\n
    <app-option [label]="mySignalProperty()"><\/code><\/pre>\n
    Computed Signals and Effects as a Replacement for Life Cycle Hooks<\/h3>\n
    All changes to the passed Signal will be reflected by the InputSignal<\/code> in the component. Internally, both Signals are connected via the graph Angular is maintaining. Life cycle hooks like ngOnInit<\/code> and ngOnChanges<\/code> can now be replaced with computed<\/code> and effect<\/code>:<\/p>\n
    markDownTitle = computed(() => '# ' + this.label())\n\nconstructor() {\n  effect(() => {\n    console.log('label updated', this.label());\n    console.log('markdown', this.markDownTitle());\n  });\n}<\/code><\/pre>\n
    Options for Input Signals<\/h3>\n
    Here are some further options for setting up an InputSignal<\/code>:<\/p>\n