In den vergangenen zwei Jahren hat das Angular-Team offenbar einen neuen Kurs eingeschlagen. Am 8. Oktober 2021 wurde in der offiziellen GitHub Repository die erste Diskussion \u00fcber Standalone-Komponenten gestartet, die als RFC (Request for Comments) vorlag. Der Beitrag war \u00e4u\u00dferst umfassend und detailliert. Die gesamte Community wurde dazu eingeladen, aktiv am Entwicklungsprozess dieses neuen Konzepts teilzunehmen.<\/p>\n\n\n\n
Die Beteiligung war erfreulich, und das Feedback sowohl seitens der Community als auch des Angular-Teams war durchweg positiv. Schlie\u00dflich wurde das Konzept der Standalone-Komponenten mit Angular 14 in das Framework integriert. Dies markierte den Anfang weiterer Diskussionen zu Themen wie \u201eSignal API\u201d, \u201eSignal-based Components\u201d und \u201eControl Flow & Deferred Loading\u201d. Auch an dieser Stelle beteiligte sich die Community intensiv.<\/p>\n\n\n\n
Die RFCs brachten keine oberfl\u00e4chlichen Anpassungen, sondern grundlegende Ver\u00e4nderungen mit sich, die dennoch z\u00fcgig vom Angular-Team in das Framework implementiert wurden. Die Signal-API wurde mit Angular 16 eingef\u00fchrt, gefolgt von einer verbesserten Template-Syntax in Angular 17. Angular 18 wird voraussichtlich die Signal-API mit den signalbasierten Komponenten abschlie\u00dfen.<\/p>\n\n\n\n
Aufgrund dieser Ver\u00e4nderungen haben unsere Xperten aus der Softwareentwicklung Angular einmal genauer unter die Lupe genommen. Im Folgenden erl\u00e4utern wir, welche Auswirkungen die Neuerungen zuk\u00fcnftig auf die Entwicklung von Angular-Anwendungen haben werden und wie man sich bereits heute darauf vorbereiten kann.<\/p>\n\n\n\n
Die typische Reactivity-API besteht aus zwei Hauptkonzepten: Signale und Effekte. Ein Signal enth\u00e4lt einen \u00e4nderbaren Wert, w\u00e4hrend ein Effekt auf \u00c4nderungen dieses Werts reagiert. F\u00fcr eine ausf\u00fchrliche Beschreibung der Umsetzung dieser API in Angular m\u00f6chten wir auf die offizielle Dokumentation verweisen: angular.dev<\/a>. Das Ziel unseres Beitrags soll nicht sein, die bestehende API zu erl\u00e4utern, sondern fortgeschrittene Angular-Entwickelnde auf die Zukunft des Frameworks vorzubereiten.<\/p>\n\n\n\n Kurz zusammengefasst basiert die Signal-API von Angular auf drei Grundelementen:<\/p>\n\n\n\n F\u00fcr Entwickelnde, die mit anderen Frameworks vertraut sind, d\u00fcrften die Parallelen zu den entsprechenden Konzepten in Angular deutlich erkennbar sein:<\/p>\n\n\n\n Angular erfindet somit das Rad nicht neu, sondern \u00fcbernimmt bew\u00e4hrte Techniken aus anderen Frameworks.<\/p>\n\n\n\n Die Einf\u00fchrung der Signal-API schafft eine klare Alternative zu RxJS, wobei das langfristige Ziel von Angular darin besteht, RxJS als zwingende Abh\u00e4ngigkeit vollst\u00e4ndig abzuschaffen. Dies birgt zahlreiche Vorteile. Neue Nutzende m\u00fcssen sich nicht mehr mit der steilen Lernkurve dieser umfangreichen Bibliothek auseinandersetzen, da sie nun s\u00e4mtliche Umsetzungen mithilfe der in Angular integrierten Tools vornehmen k\u00f6nnen. Dar\u00fcber hinaus entfallen potenzielle Probleme, die mit der Verwendung von RxJS verbunden sind, wie etwa \u201eGlitches“ aufgrund von inkonsistenten Daten und Speicherlecks bei vergessenen Subscriptions.<\/p>\n\n\n\n Obwohl RxJS weiterhin in der aktuellen Entwicklung unverzichtbar ist, insbesondere da es in den meisten f\u00fcr Angular entwickelten Bibliotheken genutzt wird, bietet das von Angular bereitgestellte Paket Signalbasierte Komponenten wurden eingef\u00fchrt, um eine nahtlose Integration von Signalen in Angular-Anwendungen zu erm\u00f6glichen. Durch das Setzen des Parameters Beispiel f\u00fcr eine signalbasierte Komponente:<\/p>\n\n\n Es ist wichtig zu beachten, dass Angular Decorator zur Compile-Zeit verarbeitet und das JavaScript-Bundle tats\u00e4chlich keine Decorator enth\u00e4lt. Die neue signalbasierte API folgt dem gleichen Ansatz. Angular verarbeitet Die Change Detection von Angular basiert entweder auf Es ist bereits m\u00f6glich, Signale innerhalb von Komponenten und ihren Templates zu verwenden. Wenn die Change-Detection-Strategie auf In signalbasierten Komponenten werden Eingabeparameter als Signale durch die Funktion zone-basiert<\/em><\/p>\n\n\n signalbasiert<\/em><\/p>\n\n\n F\u00fcr die Verwendung von Signalen als Eingabeparameter kann bereits heute ein Workaround angewendet werden. Dazu werden ein Getter und ein Setter f\u00fcr den Die Klasse zone-basiert<\/em><\/p>\n\n\n signalbasiert<\/em><\/p>\n\n\n Die Signale sind Funktionen und m\u00fcssen daher in den Templates entsprechend verwendet werden. Es erfolgt kein automatisches Entpacken durch Angular.<\/p>\n\n\n Ein aktuelles Problem im Umgang mit Signalen in Templates besteht darin, dass der gleiche R\u00fcckgabetyp bei aufeinanderfolgenden Funktionsaufrufen nicht durch den Type Guard von TypeScript garantiert werden kann. Das erschwert beispielsweise einen Nullability Check des Signalwerts im Template, um diesen als nicht null zu verwenden. Eine elegante L\u00f6sung hierf\u00fcr steht derzeit noch aus. Wir empfehlen daher, einen Verweis auf den Signalwert innerhalb eines Die herk\u00f6mmliche bidirektionale Bindung zwischen \u00fcbergeordneten und untergeordneten Komponenten erfordert etwas Boilerplate Code. Signalbasierte Komponenten hingegen vereinfachen diesen Prozess erheblich durch die Einf\u00fchrung der zone-basiert<\/em><\/p>\n\n\n signalbasiert<\/em>+<\/p>\n\n\n Es ist wichtig zu beachten, dass die \u201ebanana-in-a-box\u201c-Syntax mit den Signalen nicht funktioniert. Solange das Angular-Team keine Alternative daf\u00fcr anbietet, bleibt vorerst die Nutzung der ausf\u00fchrlicheren Variante erforderlich.<\/p>\n\n\n\n zone-basiert<\/em><\/p>\n\n\n signalbasiert<\/em><\/p>\n\n\n Das Grundprinzip der Queries bleibt in den signalbasierten Komponenten erhalten. Die \u00c4quivalente zu zone-basiert<\/em><\/p>\n\n\n signalbasiert<\/em><\/p>\n\n\n Ein m\u00f6glicher Workaround f\u00fcr Queries als Signale k\u00f6nnte \u00e4hnlich dem Ansatz f\u00fcr Eingabeparameter umgesetzt werden. Ein Setter f\u00fcr Das Angular-Team hat noch keine endg\u00fcltige Entscheidung dar\u00fcber getroffen, wie mit den beiden Decorator Die signalbasierten Komponenten bieten Unterst\u00fctzung f\u00fcr acht Lifecycle Hooks. Aufgrund ihrer urspr\u00fcnglichen Abh\u00e4ngigkeit von Um zu verdeutlichen, wie sehr die Signale unserer Leben einfacher gestalten werden, sehen wir uns nun ein Beispiel an. Als Anforderung brauchen wir eine Komponente, die als ein einziger Eingabeparameter einen Boolean erwartet. Wenn dieses \u201ewahr\u201c ist, dann startet die Komponente einen Timer, der jede Sekunde zwei zuf\u00e4llige Zahlen generiert und ihre Summe berechnet.<\/p>\n\n\n\n Zun\u00e4chst implementieren wir das Beispiel auf herk\u00f6mmliche Weise unter Verwendung der RxJS-Funktionalit\u00e4ten.<\/p>\n\n\n Trotz der geringen Komplexit\u00e4t der Aufgabe ist die Komponente unn\u00f6tig umfangreich und un\u00fcbersichtlich geworden. Der Nun setzen wir dieselbe Komponente auf signalbasierte Weise um.<\/p>\n\n\n Der Code ist erheblich k\u00fcrzer und klarer geworden.<\/p>\n\n\n\n Wir k\u00f6nnen einen Schritt weiter gehen und ein Composable definieren, um die Logik innerhalb der Komponente noch verst\u00e4ndlicher zu gestalten. Composables sind unter Entwickelnden, die mit anderen Frameworks vertraut sind, bereits bekannt und beliebt. Sie bieten eine elegante M\u00f6glichkeit, Logik in Funktionen zu kapseln und an verschiedenen Stellen im Code wiederzuverwenden. Dies tr\u00e4gt zur Schaffung klarer, modularer und wartbarer Codebasen bei.<\/p>\n\n\n\n Den Code f\u00fcr das Einrichten des Timers k\u00f6nnen wir als separate Funktion definieren. Diese Funktion soll so generisch wie m\u00f6glich sein und erwartet daher die innerhalb des Zeitintervalls auszuf\u00fchrende Logik als Callback.<\/p>\n\n\n Dieses Composable k\u00f6nnen wir nun im Konstruktor der Komponente verwenden, um unseren Code noch eleganter zu gestalten.<\/p>\n\n\n Das vorgestellte Beispiel verdeutlicht, wie die Einf\u00fchrung der neuen signalbasierten Komponenten die Entwicklung von Anwendungen beschleunigt und effizienter gestaltet. Dar\u00fcber hinaus er\u00f6ffnet die Signal-API, vor allem durch den Composable-Ansatz, einen neuen Weg f\u00fcr zahlreiche hilfreiche Bibliotheken, die das Entwickeln von Anwendungen noch zus\u00e4tzlich verbessern werden.<\/p>\n\n\n\n Die Einf\u00fchrung signalbasierter Komponenten stellt einen bedeutenden Meilenstein in der Entwicklung von Angular dar und zeichnet sich ab als der kommende Standard im Framework, vergleichbar mit der Etablierung der Standalone-Komponenten. Der \u00dcbergang zu diesem neuen Ansatz mag f\u00fcr viele Entwickelnde eine anspruchsvolle Aufgabe sein, da er eine Umstellung der Denkweise und eine Einarbeitung in innovative Konzepte erfordert. Es ist essenziell zu betonen, dass die Spezifikation der Signale und verwandter Konzepte noch nicht finalisiert ist. Entwickelnde haben die M\u00f6glichkeit, den aktuellen Fortschritt signalbasierter Komponenten im Entwicklungszweig des Angular Repositorys zu verfolgen.<\/p>\n\n\n\n F\u00fcr alle, die nicht auf offizielle Ver\u00f6ffentlichungen warten m\u00f6chten, bieten diverse Workarounds die M\u00f6glichkeit, die neuen Konzepte bereits jetzt zu integrieren. In Bezug auf bestehende Projekte mag der Wechsel zu signalbasierten Komponenten als herausfordernd erscheinen, jedoch erweist sich der Einsatz dieser bei der Entwicklung neuer Projekte bereits heute als \u00fcberlegenswert. Diese Vorgehensweise erm\u00f6glicht Entwickelnden, fr\u00fchzeitig von den Vorz\u00fcgen der neuen Funktionalit\u00e4ten zu profitieren und sich mit den zuk\u00fcnftigen Standards von Angular vertraut zu machen.<\/p>\n\n\n\n https:\/\/angular.dev\/guide\/signals<\/a> In den vergangenen zwei Jahren hat das Angular-Team offenbar einen neuen Kurs eingeschlagen. Am 8. Oktober 2021 wurde in der offiziellen GitHub Repository die erste Diskussion \u00fcber Standalone-Komponenten gestartet, die als RFC (Request for Comments) vorlag. Der Beitrag war \u00e4u\u00dferst umfassend und detailliert. Die gesamte Community wurde dazu eingeladen, aktiv am Entwicklungsprozess dieses neuen Konzepts […]<\/p>\n","protected":false},"author":4,"featured_media":771,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5],"tags":[],"class_list":["post-770","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-softwareentwicklung"],"acf":[],"yoast_head":"\n\n
signal<\/code> erzeugt ein schreibbares Signal (WritableSignal<\/code>).<\/li>\n\n\n\ncomputed<\/code> erzeugt ein berechnetes Signal (Signal<\/code>).<\/li>\n\n\n\neffect<\/code> erzeugt einen Effekt (EffectRef<\/code>).<\/li>\n<\/ul>\n\n\n"import {computed, effect, signal} from '@angular\\\/core';\\n\\nconst count = signal(1); \\\/\\\/ WritableSignal<number>\\nconst countOdd = computed(() => count() % 2 > 0); \\\/\\\/ Signal<boolean>\\neffect(() => {\\n console.log(${count()} is ${countOdd() ? 'odd' : 'even'});\\n});\\n\\nawait tick();\\n\\\/\\\/ 1 is odd\\n\\ncount.set(4);\\n\\nawait tick();\\n\\\/\\\/ 4 is even"<\/pre>\n<\/div>\n\n\n\n\n
ref<\/code>, computed<\/code>, watch<\/code>\/watchEffect<\/code><\/li>\n\n\n\nuseState<\/code>, useEffect<\/code><\/li>\n\n\n\n$state<\/code>, $derived<\/code>, $effect<\/code><\/li>\n\n\n\n@preact\/signals<\/code>: signal<\/code>, computed<\/code>, effect<\/code> (hier sogar mit denselben Bezeichnungen)<\/li>\n<\/ul>\n\n\n\nRxJS<\/h3>\n\n\n\n
@angular\/core\/rxjs-interop<\/code> die M\u00f6glichkeit, die RxJS-Observables in einer Signal-Umgebung zu verwenden. Dadurch lassen sich die Vorteile der neuen Herangehensweise optimal nutzen.<\/p>\n\n\n\nSignalbasierte Komponenten<\/h2>\n\n\n\n
signals<\/code> auf true im @Component<\/code>-Decorator wird diese neue Funktionalit\u00e4t aktiviert. Die Besonderheit dabei ist, dass signalbasierte Komponenten die Verwendung von Member-Decorators wie @Input<\/code>, @Output<\/code>, @ViewChild<\/code> etc. eliminieren. Stattdessen werden diese durch entsprechende Funktionen wie input<\/code>, output<\/code>, viewChild<\/code> usw. ersetzt. Dabei bleiben alle Optionen wie required<\/code>, alias<\/code> und transform<\/code> im @Input<\/code>-Decorator in ihren \u00c4quivalenten erhalten.<\/p>\n\n\n\n"@Component({\\n signals: true,\\n selector: 'my-temperature',\\n template: `\\n <p>C: { { celsius() }}<\\\/p>\\n <p>F: { { fahrenheit() }}<\\\/p>\\n `,\\n})\\nexport class MyTemperatureComponent {\\n celsius = input<number>({required: true});\\n\\n fahrenheit = computed(() => this.celsius() * 1.8 + 32);\\n}"<\/pre>\n<\/div>\n\n\n\ninput<\/code>, output<\/code>, viewChild<\/code> usw. zur Compile-Zeit, um die Anwendungsstruktur zu verstehen. Das bedeutet, dass diese API nicht wie herk\u00f6mmliche Funktionen im gesamten Code verwendet werden kann, sondern nur innerhalb der Komponenten funktioniert.<\/p>\n\n\n\nChange Detection<\/h3>\n\n\n\n
zone.js<\/code> oder erfordert die manuelle Verwendung der ChangeDetectorRef<\/code>-Instanz innerhalb einer Komponente. Mit der Einf\u00fchrung der signalbasierten Komponenten entf\u00e4llt jedoch die Notwendigkeit, die changeDetection<\/code>-Einstellung zu konfigurieren. Die signalbasierten Komponenten erm\u00f6glichen es Angular, automatisch Zustands\u00e4nderungen zu erkennen, sobald sich der Wert eines im Template verwendeten Signals \u00e4ndert. Diese Automatisierung eliminiert effektiv das unn\u00f6tige Neu-Rendern von Komponentenb\u00e4umen und f\u00fchrt insbesondere bei gro\u00dfen Anwendungen zu einer wesentlichen Verbesserung der Leistung.<\/p>\n\n\n\nOnPush<\/code> gesetzt ist, reagiert Angular nahtlos auf entsprechende \u00c4nderungen.<\/p>\n\n\n\nInput<\/h3>\n\n\n\n
input<\/code> definiert. Diese Signale sind schreibgesch\u00fctzt und repr\u00e4sentieren stets den aktuellen, von au\u00dfen in die Komponente eingebundenen Wert.<\/p>\n\n\n\n"@Input()\\ncount: number = 0;"<\/pre>\n<\/div>\n\n\n\n
"count = input<number>(0); \\\/\\\/ Signal<number>"<\/pre>\n<\/div>\n\n\n\n
@Input<\/code>-Decorator deklariert, um das entsprechende Signal zur\u00fcckzugeben und dessen Wert zu \u00e4ndern.<\/p>\n\n\n"@Input()\\nset count(v: number) {\\n this.#count.set(v);\\n}\\nget count(): Signal<number> {\\n return this.#count.asReadonly();\\n}\\n#count = signal<number>(0);\\n"<\/pre>\n<\/div>\n\n\n\nOutput<\/h3>\n\n\n\n
EventEmitter<\/code> ist eine Unterklasse von Subject<\/code> aus der Bibliothek RxJS. Die initiale Umsetzung der output<\/code>-Funktion soll weiterhin dieselbe EventEmitter<\/code>-Instanz zur\u00fcckgeben. Daher bleibt die Verwendung der Ausgabeparameter nahezu unver\u00e4ndert.<\/p>\n\n\n\n"@Output()\\nitemSelected = new EventEmitter<string>();\\n\\nselectItem(item: string): void {\\n this.itemSelected.emit(item);\\n}"<\/pre>\n<\/div>\n\n\n\n"itemSelected = output<string>(); \\\/\\\/ EventEmitter<string>\\n\\nselectItem(item: string): void {\\n this.itemSelected.emit(item);\\n}"<\/pre>\n<\/div>\n\n\n\nTemplate<\/h3>\n\n\n\n
"@Component({\\n \\\/*...*\\\/\\n template: `<div>{ { user().name }}<\\\/div>`,\\n})\\nexport class MyExampleComponent {\\n user = input<User>({required: true}); \\\/\\\/ Signal<User>\\n}"<\/pre>\n<\/div>\n\n\n\nif<\/code>-Blocks zu erstellen und diesen Verweis im Inhalt des Blocks zu verwenden.<\/p>\n\n\n"@Component({\\n \\\/*...*\\\/\\n template: `\\n @if (user(); as user) {\\n <div>{ { user.name }}<\\\/div>\\n } @else {\\n <div>No user is available.<\\\/div>\\n }\\n `,\\n})\\nexport class MyExampleComponent {\\n user = input<User>(); \\\/\\\/ Signal<undefined | User>\\n}"<\/pre>\n<\/div>\n\n\n\nTwo-way Binding<\/h3>\n\n\n\n
model<\/code>-Funktion. Diese Funktion erzeugt eine WritableSignal<\/code>-Instanz, die die \u00c4nderungen ihres Werts nach au\u00dfen automatisch weiterleitet.<\/p>\n\n\n\n"@Input()\\nchecked: boolean = false;\\n\\n@Output()\\ncheckedChange = new EventEmitter<boolean>();\\n\\nchangeChecked(v: boolean) {\\n this.checked = v;\\n this.checkedChange.emit(v);\\n}\\n\\ntoggle(): void {\\n this.changeChecked(!this.checked);\\n}\\n\\ncheck(): void {\\n this.changeChecked(true);\\n}\\n\\nuncheck(): void {\\n this.changeChecked(false);\\n}"<\/pre>\n<\/div>\n\n\n\n"checked = model<boolean>(false); \\\/\\\/ WritableSignal<boolean>\\n\\ntoggle(): void {\\n this.checked.update((v) => !v);\\n}\\n\\ncheck(): void {\\n this.checked.set(true);\\n}\\n\\nuncheck(): void {\\n this.checked.set(false);\\n}"<\/pre>\n<\/div>\n\n\n\n"<my-example [(checked)]=\\"value\\" \\\/>"<\/pre>\n<\/div>\n\n\n\n
"<my-example [checked]=\\"value()\\" (checkedChange)=\\"value.set($event)\\" \\\/>"<\/pre>\n<\/div>\n\n\n\n
Queries<\/h3>\n\n\n\n
@ViewChild<\/code> und @ContentChild<\/code> geben ihr Ergebnis in einem Signal zur\u00fcck. Dadurch entf\u00e4llt die Notwendigkeit, einen Setter zu definieren, falls zus\u00e4tzliche Kontrolle bei den dynamischen Queries gew\u00fcnscht ist. Die \u00c4quivalente zu @ViewChildren<\/code> und @ContentChildren<\/code> geben ihr Ergebnis ebenfalls in einem Signal zur\u00fcck, wobei statt der komplexen Klasse QueryList<\/code> ein einfaches Array verwendet wird. Das reduziert die Komplexit\u00e4t erheblich und eliminiert die Abh\u00e4ngigkeit von zus\u00e4tzlichen Observables.<\/p>\n\n\n\n"@ContentChildren(MyExampleItemComponent)\\nitems!: QueryList<MyExampleItemComponent>;\\n\\n@ViewChild('input')\\ninput?: ElementRef<HTMLInputElement>;"<\/pre>\n<\/div>\n\n\n\n"\\\/\\\/ Signal<Array<MyExampleItemComponent>>\\nitems = contentChildren(MyExampleItemComponent);\\n\\n\\\/\\\/ Signal<undefined | ElementRef<HTMLInputElement>>\\ninput = viewChild<ElementRef<HTMLInputElement>>('input');"<\/pre>\n<\/div>\n\n\n\n@ViewChild<\/code> und @ContentChild<\/code> kann mehrmals aufgerufen werden, w\u00e4hrend ein Setter f\u00fcr @ViewChildren<\/code> und @ContentChildren<\/code> nur einmal aufgerufen wird und weitere \u00c4nderungen \u00fcber ein Observable propagiert werden. Es ist auch m\u00f6glich, auf einen Getter zu verzichten, indem darauf geachtet wird, dass das erstellte Signal stets nur schreibgesch\u00fctzt verwendet wird.<\/p>\n\n\n"items = signal<Array<MyExampleItemComponent>>([]);\\n@ContentChildren(MyExampleItemComponent)\\nset _items(v: QueryList<MyExampleItemComponent>) {\\n this.items.set(v.toArray());\\n v.changes.subscribe(() => {\\n this.items.set(v.toArray());\\n });\\n}\\n\\ninput = signal<undefined | ElementRef<HTMLInputElement>>(undefined);\\n@ViewChild('input')\\nset _input(v: undefined | ElementRef<HTMLInputElement>) {\\n this.input.set(v);\\n}"<\/pre>\n<\/div>\n\n\n\nHost-Binding<\/h3>\n\n\n\n
@HostListener<\/code> und @HostBinding<\/code> verfahren werden soll. Es liegt noch keine Spezifikation vor, die eine signalbasierte Alternative vorschreibt. Derzeit wird empfohlen, vor\u00fcbergehend auf die host<\/code>-Option der @Directive<\/code>– und @Component<\/code>-Decorator zur\u00fcckzugreifen.<\/p>\n\n\n\nLifecycle Hooks<\/h3>\n\n\n\n
zone.js<\/code> werden diese Hooks in den signalbasierten Komponenten durch die Einf\u00fchrung von Signalen und Effekten \u00fcberfl\u00fcssig. Die signalbasierten Komponenten werden weiterhin die Methoden ngOnInit<\/code> und ngOnDestroy<\/code> unterst\u00fctzen, obwohl deren Verwendung optional ist. Die Initialisierung kann effektiv im Klassenkonstruktor erfolgen. Die Bereinigung, die durchgef\u00fchrt werden muss, wenn die Instanz zerst\u00f6rt wird, kann entweder im onDestroy<\/code>-Callback der injizierten DestroyRef<\/code>-Instanz oder im onDispose<\/code>-Callback innerhalb einer effect<\/code>-Methode platziert werden. Falls zus\u00e4tzliche Kontrolle \u00fcber den Rendering-Prozess innerhalb einer Komponente gew\u00fcnscht ist, bietet Angular seit der aktuellen Version (v17) drei daf\u00fcr vorgesehene Hooks an: afterNextRender<\/code>, afterRender<\/code> und afterRenderEffect<\/code>, die als Developer Preview zur Verf\u00fcgung stehen.<\/p>\n\n\n\nSignale in der Praxis<\/h2>\n\n\n\n
"export class MyExampleComponent implements OnDestroy {\\n constructor() {\\n this.subscription.add(\\n this.active$\\n .pipe(switchMap((active) => (active ? interval(1000) : EMPTY)))\\n .subscribe(() => {\\n this.n1$.next(genSomeRandomInteger());\\n this.n2$.next(genSomeRandomInteger());\\n }),\\n );\\n }\\n\\n @Input()\\n set active(v: boolean) {\\n this.active$.next(v);\\n }\\n active$ = new BehaviorSubject<boolean>(false);\\n\\n n1$ = new BehaviorSubject<number>(0);\\n\\n n2$ = new BehaviorSubject<number>(0);\\n\\n sum$ = combineLatest([\\n this.n1$.pipe(distinctUntilChanged()),\\n this.n2$.pipe(distinctUntilChanged()),\\n ]).pipe(\\n auditTime(0),\\n map(([n1, n2]) => n1 + n2),\\n share(),\\n );\\n\\n subscription = new Subscription();\\n\\n ngOnDestroy(): void {\\n this.subscription.unsubscribe();\\n }\\n}"<\/pre>\n<\/div>\n\n\n\n@Input<\/code>-Decorator erfordert einen Setter, um den Wert des Subjects zu setzen. Um \u00fcberfl\u00fcssige Berechnungen der Summe zu verhindern, muss vor jedem abh\u00e4ngigen Observable ein distinctUntilChanged<\/code>-Operator platziert werden. Die einfache Berechnung der Summe reicht nicht aus; zus\u00e4tzlich ist auch auditTime<\/code> erforderlich, um \u201eGlitches\u201d zu vermeiden, sowie share<\/code>, um sicherzustellen, dass das Observable nur einmal initialisiert wird. Im ngOnDestroy<\/code>-Hook m\u00fcssen au\u00dferdem alle Subscriptions aufger\u00e4umt werden. Es gibt viele Aspekte zu beachten, die nicht sofort intuitiv sind.<\/p>\n\n\n\n"export class MyExampleComponent {\\n constructor() {\\n effect((onCleanup) => {\\n if (this.active()) {\\n const timerId = setInterval(() => {\\n this.n1.set(genSomeRandomInteger());\\n this.n2.set(genSomeRandomInteger());\\n }, 1000);\\n onCleanup(() => {\\n clearInterval(timerId);\\n });\\n }\\n });\\n }\\n\\n active = input<boolean>(false);\\n\\n n1 = signal<number>(0);\\n\\n n2 = signal<number>(0);\\n\\n sum = computed<number>(() => this.n1() + this.n2());\\n}"<\/pre>\n<\/div>\n\n\n\n"export function useInterval(\\n active: Signal<boolean>,\\n ms: number,\\n callback: {(): void},\\n): void {\\n effect((onCleanup) => {\\n if (active()) {\\n const timerId = setInterval(callback, ms);\\n onCleanup(() => {\\n clearInterval(timerId);\\n });\\n }\\n });\\n}"<\/pre>\n<\/div>\n\n\n\n"constructor() {\\n useInterval(this.active, 1000, () => {\\n this.n1.set(genRandomInteger(1, 6));\\n this.n2.set(genRandomInteger(1, 6));\\n });\\n}"<\/pre>\n<\/div>\n\n\n\nFazit<\/h2>\n\n\n\n
Quellen<\/h2>\n\n\n\n
https:\/\/github.com\/angular\/angular\/discussions<\/a>
https:\/\/github.com\/angular\/angular\/tree\/signals<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"