Déclarations @let angulaires : abonnements à des modèles intelligents

Depuis quelques temps, Angular vit sur sa lancée et l'équipe Angular a prouvé qu'elle se souciait de sa communauté. Dans Angular v17 et les versions mineures suivantes, l'équipe Angular a fourni de nombreuses fonctionnalités intéressantes, dont l'une qui s'est le plus démarquée, même si dans l'aperçu du développeur, était la nouvelle syntaxe de modèle bloc intégrée qui simplifiait travailler avec des modèles.

Dans la version récente, deux numéros tant attendus du dépôt Angular ont été fermés. La version majeure d'Angular, v18, incluait les événements de changement d'état de contrôle unifié, entre autres fonctionnalités, et la version mineure, v18.1, tirait parti de la syntaxe du modèle block en ajoutant une nouvelle fonctionnalité intégrée au modèle. connu sous le nom de Variables locales du modèle, désignées par le bloc @let.

Consultez le billet de blog officiel pour en savoir plus sur la façon dont les variables @let sont définies, fonctionnent, les limitations et comment elles mettent à jour leurs valeurs.

En termes simples, Variables locales de modèle, permettent aux développeurs Angular de déclarer des variables dans leurs modèles, tout comme nous le faisons dans la classe du composant, rationalisant la façon dont nous écrivons la logique dans le modèle, apportant ainsi des alternatives à certains anciens modèles de modèles et introduction de nouveaux cas d'utilisation abordés dans cet article de @eneajaho.

La motivation de cet article est venue d'un fil de discussion Reddit se demandant si les déclarations @let étaient nécessaires et pourquoi elles devraient être utilisées.

Vous pouvez retrouver le point de vue du principal contributeur d'Angular, Matthieu Riegler, sur ce sujet ici.

Dans cet article, je souhaite montrer un cas d'utilisation de ces variables de modèle locales que j'ai trouvées utiles sur un projet sur lequel je travaille, où je n'ai plus besoin de faire la « mise en cache » avec le RxJS shareReplay de la classe du composant pour utiliser le même élément de données dans différentes sections du modèle.

Plongeons-nous ?.

---

"Mise en cache" RxJS avec l'opérateur shareReplay

Lors du développement d'applications Web, la chose la plus courante que font les développeurs est de faire des requêtes HTTP. Dans Angular, la communication HTTP s'effectue via une API basée sur les observables, le populaire

HttpClient. Étant donné que dans la plupart des cas, les données récupérées sont liées dans le modèle, les développeurs suivent l'approche déclarative avec le tube Async comme meilleure pratique : s'abonne automatiquement à l'observable dans le modèle et se désabonne lorsque le composant est détruit ? :

...
@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');
}

Mais il y a des cas où nous avons besoin des données du même flux ailleurs dans le modèle, nous lions donc à nouveau le flux observable dans le modèle avec le tube

Async ?:

...
@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');
}

Cela se traduit par le fait que le même flux observable est lié et abonné dans deux sections différentes du modèle, ce qui donne lieu à deux requêtes HTTP en double en cours pour récupérer inutilement le même élément de données ? :

Une solution courante dans ce cas (j'ai vu) consiste à mettre en cache les données de la première requête HTTP lancée à l'aide de RxJS via l'opérateur

shareReplay :

...
@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)); ?
}

Cela garantit que même si le même flux observable est lié et abonné avec le canal

Async à plusieurs endroits du modèle, une seule requête HTTP sera déclenchée et les données de réponse seront mises en cache ?:

Ce modèle fonctionne bien mais pouvons-nous réaliser cette fonctionnalité plus simplement ?

Découvreons ?.

Déclarations @let pour la rationalisation

Bien que la solution RxJS fonctionne bien et réponde à nos besoins, les déclarations

@let introduites dans Angular v18.1 offrent une alternative plus simple, basée sur un modèle ?:

...
@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');
}

Comme on peut le remarquer, il propose une sorte de « mise en cache basée sur un modèle » — lier et s'abonner à la requête HTTP observable une seule fois dans le modèle ?:

Par conséquent, aucune requête HTTP en double n'est sortante et aucune mise en cache RxJS via l'opérateur

shareReplay n'est requise. ??

Remarque ? : Cette solution fonctionne lors de la mise en cache des données pour le modèle. L'opérateur

shareReplay est requis si des données mises en cache sont nécessaires dans la classe du composant.

---

Un merci spécial à @kreuzerk et @eneajaho pour la critique.

Merci d'avoir lu !

J'espère que ça vous a plu ?. Si vous avez aimé l'article, partagez-le avec vos amis et collègues.

Pour toute question ou suggestion, n'hésitez pas à commenter ci-dessous ?.

Si cet article vous est intéressant et utile, et que vous ne voulez pas manquer les prochains articles, suivez-moi sur @lilbeqiri, dev.to ou Medium. ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!