Les résolveurs angulaires sont-ils sous assistance respiratoire ?

Je parcourais Tech Twitter il y a quelques mois, quand j'ai vu ce tweet du tristement célèbre Brandon :

Si vous ne le savez pas, Brandon a créé AnalogJS, le méta-framework de type NextJS pour Angular. Je suis un grand fan de ce qu'il fait pour la communauté Angular, j'ai donc dû répondre. Il sera le premier à vous dire que je veux tout résoudre avec des résolveurs.

Et...

Pas un... un seul... like ou réponse.

Je ne publie pas beaucoup sur Twitter et je n'ai pas non plus d'abonnés, donc je n'y ai rien pensé.

Cependant, je suis tombé à nouveau sur ce post par hasard et j'ai lu les commentaires, et j'ai réalisé que personne n'était d'accord avec moi ! Honnêtement, je me demande s'ils comprennent même de quoi je parle.

Deux façons de charger des données

Il existe en fait deux paradigmes populaires en JavaScript pour charger des données.

1. À l'intérieur du composant

C'est la première façon dont j'ai appris Angular. Lorsque j'ai suivi pour la première fois le cours Angular original de Fireship, je n'ai même jamais entendu parler des résolveurs. Les résolveurs ne sont pas populaires et je pense qu'ils sont extrêmement mal compris.

L'exemple de Brandon ci-dessus montre les données chargées APRÈS le rendu du composant. C'est le même modèle pour les autres frameworks :<script> // Detect dark theme var iframe = document.getElementById('tweet-1836847595806732317-750'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1836847595806732317&theme=dark" } </script>

• React Query - Tanstack Query utilise useEffect sous le capot. Peut-être que le premier modèle de récupération a été créé dans React.
• Vue recommande de regarder
• SolidJS - utilise createResource qui renvoie un signal
• Qwik - a useResource$, qui renvoie un signal
• Svelte - aucune utilisation recommandée sur GH pour Svelte pur, bien que vous deviez utiliser $effect avec .then() au lieu d'async. Svelte 4 utilise des magasins, qui suivraient le même modèle non recommandé à l'intérieur du magasin. Voir Svelte 5 avec Firebase
• Angular - Angular a toujours recommandé le modèle Observable/Behavioral Subject, et maintenant vous pouvez simplement utiliser effect(). Cependant, ngxtension a un dérivéAsync pour le faire pour vous, et Angular 19 aura une ressource() intégrée. En réalité, RxJS est encore trop étroitement lié à Angular, aux intercepteurs et au client http de la vieille école.

2. À l'intérieur d'une fonction de chargement

• NextJS - ce qui était auparavant getServerSideProps n'est plus qu'une fonction asynchrone à l'intérieur d'un composant serveur. Vous êtes uniquement un serveur ou un package externe comme React Query.
• Nuxt - Nuxt a intégré des fonctions de récupération $fetch qui gèrent la récupération une fois sur le client et l'hydratation du navigateur. Vous pouvez également récupérer l'intérieur d'un composant serveur comme dans NextJS.
• SvelteKit - la seule méthode recommandée dans Svelte ou SvelteKit est à l'intérieur d'une fonction de chargement. Cela s'exécute AVANT que le composant ne soit monté et peut s'exécuter sur le serveur ou le client. Ils ne sont PAS réservés au serveur.
• QwikCity - QwikCity dispose de routeLoader$ et server$ pour le préchargement des données. Qwik "reprend", qui ne nécessite pas d'hydratation et ne s'exécute qu'une seule fois.
• SolidStart - utilise une fonction de requête et avec un préchargement qui s'exécute sur chaque itinéraire.
• Angulaire - Angular possède des résolveurs, qui sont parfaits pour ce cas d'utilisation. Cependant, plus personne ne semble les utiliser.

Quel est ton point ?

Avez-vous remarqué une tendance ici ? Les frameworks côté serveur préfèrent les fonctions de chargement (résolveur), tandis que les frameworks clients récupèrent les données dans un signal de manière réactive. Mais...

Angular n'est PAS un framework côté serveur !

Le problème n'est pas qu'Angular n'est pas un framework SSR, le problème est qu'il prétend l'être.

1. L'ajout de @angular/ssr n'ajoute en fait aucune fonctionnalité du serveur en dehors de l'hydratation et de l'état de transfert automatique (sauf dans le résolveur bien sûr). Néanmoins, techniquement, React possède des composants serveur, tandis que NextJS en profite. Les fonctionnalités manquantes incluent, sans s'y limiter, la prise en charge de .env, les points de terminaison, les composants du serveur, les actions de formulaire, la mise en cache du serveur, le préchargement des données à partir du serveur uniquement, bun, deno, cloudflare, la prise en charge non-nodejs et bien sûr le routage basé sur les fichiers. Lisez n'importe lequel de mes articles précédents pour contourner ces problèmes.
2. Remarquez que Firebase App Hosting ne prend en charge que Angular et NextJS, mais PAS Analog, qui est le véritable framework Angular Server Side !

Maintenant, je ne m'attends pas à ce que l'équipe Angular ajoute toutes mes demandes de fonctionnalités. Cependant, ce serait bien d'avoir une prise en charge de base de .env dans le constructeur principal et la possibilité de créer des points de terminaison avec le routeur angulaire. Brandon peut s’occuper du reste.

C'est aussi toujours fou pour moi de ne pas pouvoir déployer une application Angular SSR de base sur Vercel.

Pourquoi ne pas récupérer de manière réactive ?

J'ai lu un article sur les résolveurs de 2019 qui dit que le cas d'utilisation des résolveurs est "très rare". Fondamentalement, vous ne devez les utiliser que lorsque vous récupérez des données pouvant se charger rapidement. D'accord, d'accord. En réalité, vous ne chargeriez des données lentes que dans de rares cas d'utilisation. Vous souhaitez que votre site ou votre application soit rapide.

? Qu'est-ce que c'est, mec...

Que dirait Josh Morony ?

Vous ne devez pas utiliser RxJS dans Angular, sauf si vous devez gérer des événements asynchrones avec des conditions de concurrence ou coordonner un flux de données complexe.

Il faisait là référence à Signals VS Observables, donc je n'en ai aucune idée. Néanmoins, j'aime penser que vous devriez simplement récupérer le résolveur par défaut JUSQU'à ce que vous ayez ces cas d'utilisation avancés.

Tu n'as vraiment pas le choix...

Si vous créez une application SSR professionnelle, vous aurez besoin d'un référencement généré à partir d'une base de données. Vous DEVEZ utiliser un résolveur ou suspendre manuellement le chargement du composant avec PendingTask, ce qui est extrêmement génial.

En analogique, je soupçonne que les gens récupèrent uniquement à l'intérieur des points de terminaison basés sur des fichiers, ou qu'ils génèrent des pages statiques là où cela n'a pas d'importance.

Svelte VS Angulaire

Les modèles de programmation de mes deux frameworks préférés sont aux antipodes.

• Huntabyte va vous montrer la manière recommandée --- il n'y a pas d'autre moyen --- de charger des données à l'aide des fonctions de chargement de page.
• Pendant ce temps, la communauté angulaire et analogique rejette les résolveurs et montre leur manière réactive sans doute plus compliquée.

Diffusion HTTP

Une réponse populaire au chargement lent dans le résolveur est le streaming HTTP. NextJS et SvelteKit le prennent en charge, mais cela a été refusé pour Angular.

?

En réfléchissant à cela... TL;DR

• Angular n'est pas un framework SSR complet
• La communauté utilise rarement des résolveurs pour charger des données asynchrones
• Les membres de l'équipe Angular citent souvent Analog comme une raison de NE PAS changer les choses
• Ce n'est pas nécessairement une mauvaise chose, juste à l'opposé de la communauté Svelte
• La gestion des conditions de concurrence, l'abandon des contrôleurs, les actions observables ou toute récupération complexe est toujours meilleure dans le composant
• Le préchargement des données pour le référencement est toujours meilleur dans un résolveur
• Svelte peut parfois utiliser un peu de RxJS
• Les résolveurs devraient avoir la possibilité d'utiliser des signaux comme input()
• La communauté Angular SSR est-elle petite ?
• La plupart des gens créent-ils simplement des applications d'entreprise tout en les récupérant dans une autre langue ?
• Le référencement n'a-t-il pas d'importance pour la PLUPART des utilisateurs d'Angular SSR, ou est-ce juste une réflexion après coup ?
• Le streaming HTTP serait cool dans Angular, ainsi que la reprise lorsque Wiz est combiné.

État

Actuellement, tout ce qui se trouve dans le résolveur sera récupéré deux fois (client serveur). Cela devra également être géré à l’avenir. ? Les résolveurs devraient transmettre l'état automatiquement... utilisez ma fonction useAsyncTrasferState dans un résolveur pour cela.

Comparaison des deux approches

J'ai utilisé ngxtension pour la démo par souci de concision, mais le résultat est le même.

Version d'effet

  id = injectParams('id');

  idNumber = computed(() => Number(this.id()));

  todo = derivedAsync<Todo>(() =>
    fetch(`https://jsonplaceholder.typicode.com/todos/${this.id()}`).then(
      (response) => response.json()
    )
  );

  prevId = computed(() => Math.max(this.idNumber() - 1, 1));
  nextId = computed(() => this.idNumber() + 1);

Version du résolveur

  todo = injectRouteData<Todo>('data');

  idNumber = computed(() => this.todo()!.id);

  prevId = computed(() => Math.max(this.idNumber() - 1, 1));
  nextId = computed(() => this.idNumber() + 1);

Ceci est chargé depuis le résolveur.

import { ResolveFn } from '@angular/router';

export const routeResolverResolver: ResolveFn<boolean> = async (route) => {

  const todoId = route.paramMap.get('id');

  if (!todoId) {
    throw new Error('Todo ID is missing in the route!');
  }

  // Fetch the todo from the API
  const response = await fetch(`https://jsonplaceholder.typicode.com/todos/${todoId}`);

  if (!response.ok) {
    throw new Error('Failed to fetch the todo');
  }

  return await response.json();
};

Quel est le meilleur ?

Dans cette démo particulière, il y a un "scintillement" dans la version effet, alors qu'il n'y a pas de scintillement dans la version résolveur. Je pense que le résolveur est meilleur dans ce cas d'utilisation.

Qu'en pensez-vous ?

? Étant donné que Vercel ne prend pas en charge le déploiement SSR, la démo charge le résolveur uniquement sur le client. Cela signifie que le routage ne fonctionne qu'à partir de la page d'accueil.

• Démo : Vercel (SSR ne fonctionne pas avec Vercel)
• Repo : GitHub

Répondre

Je dirais qu'il est sous assistance respiratoire pour les récupérations asynchrones. En réalité, les utilisateurs d'Angular SSR devraient envisager davantage les résolveurs pour ce cas d'utilisation et les utilisateurs de SvelteKit devraient envisager de charger $effect() pour davantage de cas d'utilisation. Mais c'est peut-être là le but ? La base d'utilisateurs est différente.

J'apprends encore, mais ces questions me fascinent. Espérons que nous assistons à davantage de bouleversements dans les deux écosystèmes.

J

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!