Angular @let-Deklarationen: Smart Template-Abonnements

Seit einiger Zeit lebt Angular in seiner Dynamik und das Angular-Team hat bewiesen, dass ihm die Community am Herzen liegt. In Angular v17 und den folgenden Nebenversionen lieferte das Angular-Team viele großartige Funktionen, von denen eines, auch wenn es in der Entwicklervorschau vorkam, die neue integrierte Block-Vorlagensyntax war, die vereinfacht wurde Arbeiten mit Vorlagen.

In der aktuellen Version wurden zwei lang erwartete Probleme im Angular-Repo behoben. Die Hauptversion von Angular, Version 18, lieferte unter anderem die Unified Control State Change Events, und die Nebenversion, Version 18.1, nutzte die Block-Vorlagensyntax, indem sie der Vorlage eine neue integrierte Funktion hinzufügte bekannt als Template Local Variables, gekennzeichnet durch den @let-Block.

Schauen Sie sich den offiziellen Blogbeitrag an, um mehr darüber zu erfahren, wie @let-Variablen definiert sind, funktionieren, Einschränkungen haben und wie sie ihre Werte aktualisieren.

Einfach ausgedrückt: Lokale Vorlagenvariablen ermöglichen es Angular-Entwicklern, Variablen in ihren Vorlagen zu deklarieren, genau wie wir es in der Klasse der Komponente tun. Dadurch wird die Art und Weise optimiert, wie wir die Logik in der Vorlage schreiben, wodurch Alternativen für einige geschaffen werden alte Vorlagenmuster und Einführung neuer Anwendungsfälle, die in diesem Artikel von @eneajaho behandelt wurden.

Die Motivation für diesen Artikel kam von einem Reddit-Thread, in dem die Frage gestellt wurde, ob @let-Deklarationen erforderlich seien und warum sie verwendet werden sollten.

Die Meinung des Hauptautors von Angular, Matthieu Riegler, zu diesem Thema finden Sie hier.

In diesem Artikel möchte ich einen Anwendungsfall dieser lokalen Vorlagenvariablen zeigen, die ich bei einem Projekt, an dem ich arbeite, als nützlich empfand, bei dem ich das „Caching“ mit dem RxJS nicht mehr durchführen muss shareReplay-Operator aus der Klasse der Komponente zur Verwendung desselben Datenelements in verschiedenen Vorlagenabschnitten.

Lass uns eintauchen?.

---

RxJS-„Caching“ mit dem ShareReplay-Operator

Bei der Entwicklung von Webanwendungen stellen Entwickler am häufigsten HTTP-Anfragen. In Angular erfolgt die HTTP-Kommunikation über eine beobachtbare API, den beliebten HttpClient. Da in den meisten Fällen die abgerufenen Daten in der Vorlage gebunden sind, folgen Entwickler dem deklarativen Ansatz mit der Async-Pipe als Best Practice – abonniert automatisch das Observable in der Vorlage und kündigt das Abonnement, wenn die Komponente zerstört wird? :

...
@Component({
  ...
  template: `
    ...
    <main>
      ...            ?
      @if (todo$ | async; as todo) {
        <p>Title: {{todo.title}}</p>
      }
    </main>
   ...
  `,
  standalone: true,
  ...
})
export class ShareReplayComponent {
  todo$ = inject(HttpClient)
    .get<Todo>('https://jsonplaceholder.typicode.com/todos/1');
}

Aber es gibt Fälle, in denen wir die Daten aus demselben Stream an einer anderen Stelle in der Vorlage benötigen, also binden wir den beobachtbaren Stream in der Vorlage erneut mit der Async-Pipe ?:

...
@Component({
  template: `
    ...
    <main>
      ...           ?
      @if (todo$ | async; as todo) {
        <p>Title: {{todo.title}}</p>
      }
    </main>

    <aside>
      ...            ?
      @if (todo$ | async; as todo) {
        <p>Is Completed: {{todo.completed}}</p>
      }
    </aside>
   ...    
  `,
  standalone: true,
})
export class ShareReplayComponent {
  todo$ = inject(HttpClient)
    .get<Todo>('https://jsonplaceholder.typicode.com/todos/1');
}

Dies führt dazu, dass derselbe beobachtbare Stream in zwei verschiedenen Abschnitten der Vorlage gebunden und abonniert wird, sodass zwei doppelte HTTP-Anfragen laufen, um unnötigerweise dasselbe Datenelement abzurufen?:

Eine gängige Lösung für diesen Fall (ich habe gesehen) besteht darin, die Daten der ersten ausgelösten HTTP-Anfrage mithilfe von RxJS über den shareReplay-Operator:
zwischenzuspeichern

...
@Component({
  template: `
    ...
    <main>
      ...            ?
      @if (todo$ | async; as todo) {
        <p>Title: {{todo.title}}</p>
      }
    </main>

    <aside>
      ...            ?
      @if (todo$ | async; as todo) {
        <p>Is Completed: {{todo.completed}}</p>
      }
    </aside>
   ...
  `,
  standalone: true,

})
export class ShareReplayComponent {
  todo$ = inject(HttpClient)
    .get<Todo>('https://jsonplaceholder.typicode.com/todos/1')
    .pipe(shareReplay(1)); ?
}

Dadurch wird sichergestellt, dass, obwohl derselbe beobachtbare Stream an mehreren Stellen in der Vorlage mit der Pipe Async gebunden und abonniert wird, nur eine HTTP-Anfrage ausgelöst wird und die Antwortdaten zwischengespeichert werden ?:

Dieses Muster funktioniert gut, aber können wir diese Funktionalität einfacher erreichen?

Lass es uns herausfinden?.

@let-Deklarationen zur Optimierung

Obwohl die RxJS-Lösung gut funktioniert und unsere Anforderungen erfüllt, bieten die in Angular v18.1 eingeführten @let-Deklarationen eine einfachere, vorlagenbasierte Alternative ?:

...
@Component({
  template: `
    ...
    @let todo = todo$ | async; ?
    <main>
      ...
      @if (todo) {
        <p>Title: {{todo.title}}</p>
      }
    </main>

    <aside>
      ...
      @if (todo) {
        <p>Is Completed: {{todo.completed}}</p>
      }
    </aside>
   ...
  `,
  standalone: true,

})
export class LetVariablesComponent {
  todo$ = inject(HttpClient)
    .get<Todo>('https://jsonplaceholder.typicode.com/todos/1');
}

Wie Sie sehen können, bietet es eine Art „vorlagenbasiertes Caching“ – binden und abonnieren Sie die HTTP-Anfrage, die nur einmal in der Vorlage beobachtbar ist?:

Dadurch gehen keine doppelten HTTP-Anfragen aus und es ist kein RxJS-Caching über den shareReplay-Operator erforderlich. ??

Hinweis?: Diese Lösung funktioniert beim Zwischenspeichern von Daten für die Vorlage. Der Operator shareReplay ist erforderlich, wenn zwischengespeicherte Daten in der Klasse der Komponente benötigt werden.

---

Besonderer Dank geht an @kreuzerk und @eneajaho für die Rezension.

Danke fürs Lesen!

Ich hoffe es hat dir gefallen? Wenn Ihnen der Artikel gefallen hat, teilen Sie ihn bitte mit Ihren Freunden und Kollegen.

Bei Fragen oder Anregungen können Sie gerne unten einen Kommentar abgeben?.

Wenn dieser Artikel für Sie interessant und nützlich ist und Sie zukünftige Artikel nicht verpassen möchten, folgen Sie mir unter @lilbeqiri, dev.to oder Medium. ?

Das obige ist der detaillierte Inhalt vonAngular @let-Deklarationen: Smart Template-Abonnements. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!