Premières impressions d'Astro : ce que j'ai aimé et ce que je n'ai pas aimé-js tutoriel-php.cn

First impressions of Astro: what I liked and disliked

J'ai récemment commencé à utiliser Astro pour reconstruire des projets parallèles initialement construits avec WordPress, Go, Rails et Hugo. J'ai choisi Astro parce qu'il avait un DX de type React avec une bonne prise en charge des serveurs de langage et parce qu'il était compatible avec les plates-formes d'hébergement sans serveur dotées d'un niveau gratuit généreux (Cloudflare, AWS Lambda, etc.).

Je ne connaissais pas grand-chose à Astro lorsque j'ai commencé à l'utiliser. Maintenant que j'ai migré plusieurs sites, je voulais partager ce que j'ai aimé et ce que je n'ai pas aimé dans le framework avec toute autre personne envisageant de l'utiliser.

Astro : ce que j'ai aimé

À la base, Astro est un générateur de sites statiques avec la capacité de produire des pages dynamiques rendues par le serveur en cas de besoin. Astro convient parfaitement aux blogs ou aux petits sites marketing avec une interactivité limitée. Le framework fournit la plupart des DX de Next.js sans la surcharge de React.js.

Bon IntelliSense et formatage du code dans un langage de modèle rendu par le serveur

Soyons honnêtes : une bonne prise en charge des serveurs de langage et un bon formatage du code font cruellement défaut dans les langages de création de modèles traditionnels rendus par le serveur. Les modèles Go, Jinja, ERB et EJS sont terriblement en retard en termes d'outils par rapport à leurs homologues React/Vue/Svelte. La plupart des langages de création de modèles rendus par le serveur n'ont aucun moyen de savoir quelles variables sont concernées ni quels sont leurs types.

Avec Astro, toutes ces fonctionnalités sont accessibles en une seule extension VS Code.

Dans les modèles Astro, vous définissez vos données en haut du modèle à l'intérieur d'une "clôture de code" qui s'exécute soit au moment de la construction, soit en répondant à une requête sur le serveur. Voici à quoi cela ressemble en pratique :

---
import Layout from "../layouts/Layout.astro";
import { getPosts } from "../data/posts";

const posts: { id, title }[] = await getPosts();
---
<Layout pageTitle="Posts">
  <h1>Posts</h1>

  {post.length > 0 ? (
    <ul>
      {posts.map((post) => (
        <li>
          <a href={`/posts/${post.id}`}>
            {post.title}
          </a>
        </li>
      )}
    </ul>
  ) : null}
</Layout>

Copier après la connexion

Étant donné que toutes les données du modèle sont chargées dans la « barrière de code » au-dessus du modèle, le serveur de langage peut fournir une saisie semi-automatique pour les propriétés de tout objet défini dans la portée. Il indiquera également lorsque vous essayez d'utiliser une variable qui n'existe pas.

Les fichiers Astro peuvent être des "composants"

L'un de mes plus gros reproches aux langages de création de modèles traditionnels comme les modèles Go, Jinja et EJS est qu'ils n'ont pas de « composants » pouvant accepter les enfants. La plupart de mes sites Web disposent d'un élément d'interface utilisateur "conteneur" à largeur limitée, qui garantit que le contenu ne s'affiche pas jusqu'au bout de l'écran sur les moniteurs ultra-larges. Si vous disposez d'une classe .container que vous ajoutez manuellement à

éléments, alors cela fonctionne généralement bien. Cependant, si vous utilisez un framework CSS utilitaire comme Tailwind, vous risquez de vous retrouver à ajouter le code suivant à chaque modèle de page :

<div
 >



<p>When you eventually need to change these classes, it's an error-prone pain to update each file manually. But if your templating language doesn't have components that can accept children, it's almost inevitable. </p>

<p>Unlike those traditional templating languages, Astro templates can be used as components that accept children using a <slot /> tag. A long string of utility classes could be extracted into a reusable Astro component:<br>


<pre class="brush:php;toolbar:false"><div
 >



<p>The Astro component could then be consumed from another Astro file.<br>
</p>

<pre class="brush:php;toolbar:false">---
import Container from "../components/Container.astro";
---
<Container>
  <h1>Hello, world!</h1>
</Container>

Copier après la connexion

Les fichiers Astro ne se limitent pas à un seul emplacement : ils peuvent en avoir plusieurs.

Ma fonctionnalité préférée des composants Astro est qu'ils peuvent accepter des accessoires dans la limite du code. Voici un exemple :

---
import Layout from "../layouts/Layout.astro";
import { getPosts } from "../data/posts";

const posts: { id, title }[] = await getPosts();
---
<Layout pageTitle="Posts">
  <h1>Posts</h1>

  {post.length > 0 ? (
    <ul>
      {posts.map((post) => (
        <li>
          <a href={`/posts/${post.id}`}>
            {post.title}
          </a>
        </li>
      )}
    </ul>
  ) : null}
</Layout>

Copier après la connexion

Le composant peut alors accepter des accessoires lorsqu'il est utilisé dans un autre fichier.

<div
 >



<p>When you eventually need to change these classes, it's an error-prone pain to update each file manually. But if your templating language doesn't have components that can accept children, it's almost inevitable. </p>

<p>Unlike those traditional templating languages, Astro templates can be used as components that accept children using a <slot /> tag. A long string of utility classes could be extracted into a reusable Astro component:<br>


<pre class="brush:php;toolbar:false"><div
 >



<p>The Astro component could then be consumed from another Astro file.<br>
</p>

<pre class="brush:php;toolbar:false">---
import Container from "../components/Container.astro";
---
<Container>
  <h1>Hello, world!</h1>
</Container>

Copier après la connexion

Un pipeline d'actifs frontend avec rechargements en direct est intégré

J'ai déjà créé mes propres intégrations côté serveur avec Vite. Si vous essayez de mettre quelque chose en ligne rapidement, c'est le genre de fonctionnalité standard que vous souhaitez éviter de créer vous-même. Avec Astro, c'est intégré.

Si vous souhaitez ajouter un script personnalisé à une page ou un composant Astro, tout ce que vous avez à faire est de déposer une balise de script sur la page.

---
type Props = { pageTitle: string; pageDescription: string };

const { pageTitle, pageDescription } = Astro.props;
---

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>{pageTitle}</title>
    <meta name="description" content={pageDescription} />
  </head>
  <body>
    <slot />
  </body>
</html>

Copier après la connexion

Astro compilera automatiquement les fichiers TS et JS dans le cadre du processus de création d'un site. Vous pouvez également écrire des scripts qui utilisent les importations de node_modules à l'intérieur d'une balise de script dans un composant Astro, et Astro le compilera pendant le temps de construction et l'extraira dans son propre fichier.

---
import Layout from "../layouts/Layout.astro";
---
<Layout
  pageTitle="Tyler's Blog"
  pageDescription="I don't really post on here."
>
  <h1>Tyler's blog</h1>
  <p>Sorry, there's no content yet...</p>
</Layout>

Copier après la connexion

Vous pouvez inclure des styles CSS ou Scss dans un fichier Astro en les important dans la clôture de code.

<div>
  <h1>This is my page</h1>
  <script src="../assets/script.ts"></script>
</div>

Copier après la connexion

Astro offre également la possibilité de créer des styles étendus en utilisant une balise de style dans un fichier Astro. Cette fonctionnalité est peut-être familière aux utilisateurs de Vue.

Étant donné le fichier Astro suivant :

<script>
  // This will also compile down to a JavaScript file at build time.

  import axios, { type AxiosRequestConfig, type AxiosResponse } from "axios";

  const response = await axios
    .get<AxiosRequestConfig, AxiosResponse<{foo: string}>>("/some-endpoint");

  console.log(response.data.foo);
</script>

Copier après la connexion

Facile, non ?

Actes

Les actions fournissent un moyen sécurisé d'exécuter des fonctions backend. Ils fournissent une validation et peuvent gérer à la fois les données JSON et les données de formulaire. Ils constituent facilement l'une des fonctionnalités phares d'Astro : tout cela devrait être câblé à la main dans une application Next.js de manière sur mesure. Ils nécessitent un peu plus de code que ce qui peut parfaitement tenir dans un exemple, mais ils sont assez élégants à utiliser. Je vous recommande de lire la page de documentation sur les actions.

Aucun coût d'exécution JS

Il existe un nombre infini de développeurs Twitter qui affirment que React est « assez rapide ». Pour beaucoup de choses, ce n'est pas le cas.

J'utilise Rasbperry Pi 4 pour de petits projets, et vous pouvez ressentir le coût d'exécution de React. Je suis sûr que c'est la même chose pour les téléphones Android bon marché, sauf que dans ce cas, la surcharge JS épuisera également la batterie.

Si la seule interactivité dont mon site a besoin est d'activer un menu de navigation, je préfère le câbler moi-même. J'utiliserai volontiers React quand j'en aurai besoin, mais pour de nombreux projets, je n'en ai pas réellement besoin.

Astro : ce que je n'ai pas aimé

Les choses que je n'aime pas chez Astro ne sont pas propres au framework : ce sont des idées empruntées à d'autres outils de l'écosystème JavaScript.

Routage basé sur des fichiers

Étant donné qu'Astro utilise un routage basé sur des fichiers, la moitié des fichiers d'un projet Astro finissent par être nommés index.(astro|js|ts) ou [id].(astro|js|ts). Le routage basé sur les fichiers est un modèle odieux qui a balayé le monde du front-end après sa mise en œuvre par Next.js, et il présente de nombreux inconvénients :

Vous aurez souvent 5 onglets ouverts dans votre éditeur avec le même nom de fichier. Il faudra au moins 3 tentatives pour trouver l'onglet que vous recherchez.
Le chercheur flou de fichiers de l'éditeur est beaucoup moins utile car de nombreux fichiers portent le même nom.
Le routage basé sur les fichiers disperse l'une des principales préoccupations d'une application sur de nombreux fichiers et dossiers, ce qui rend difficile la visualisation de tous les itinéraires d'un seul coup d'œil dans l'éditeur. Au lieu de cela, vous devez explorer plusieurs dossiers pour comprendre quelles pages sont disponibles.

Je l'admets : le routage basé sur des fichiers est très agréable lorsque vous créez un site de moins de 10 pages. Mais à mesure qu'un site se développe, cela ajoute des frictions et vous combattez la fonctionnalité plus que vous n'en bénéficiez.

Dans l'écosystème JavaScript, Remix se distingue en proposant une version de routage basé sur des fichiers qui aplatit toutes les routes dans un seul répertoire et permet à un utilisateur de désactiver entièrement le routage basé sur des fichiers avec une configuration manuelle des routes.

Le routage basé sur des fichiers est mon plus gros reproche à propos d'Astro, mais c'est une fonctionnalité difficile à échapper. Il est implémenté dans Next.js, Nuxt.js, SvelteKit et autres. Ce qui est encore plus étrange, c'est que ces frameworks sont en grande partie sans opinion sur les noms de fichiers des autres parties de l'application. Contrairement à Ruby on Rails, la plupart des frameworks JavaScript vous offrent un grand degré de liberté dans les noms de fichiers et la structure du projet –sauf pour le routage. C'est un cas particulier, et les cas particuliers ajoutent de la complexité au logiciel.

Un composant par fichier (en quelque sorte)

Une fonctionnalité du langage JavaScript que j'aime beaucoup est la possibilité de définir plusieurs variables, fonctions et classes dans un seul fichier. Cela facilite la colocalisation des fonctionnalités associées sans avoir à les extraire prématurément vers d'autres fichiers en raison de contraintes au niveau de la langue.

Tout comme les composants à fichier unique de Vue, les fichiers Astro permettent de définir un composant par fichier. Cela me semble fastidieux, mais Astro propose une solution de contournement.

Astro peut intégrer des composants React, Vue, Svelte, Solid et Preact pré-rendus directement dans ses modèles sans charger de JavaScript côté client. Les composants Preact se marient raisonnablement bien avec Astro car Preact JSX est beaucoup plus proche du HTML que de React JSX. Cependant, il devient difficile de gérer les composants Astro et Preact dans le même projet, et une fois que je commence à utiliser les composants Preact, je me retrouve à déplacer la plupart de l'interface utilisateur des fichiers Astro vers Preact.

Réflexions finales sur Astro

Si vous êtes un utilisateur assidu de Next.js, Nuxt ou SvelteKit et que vous êtes satisfait de votre framework, vous ne tirerez peut-être pas grand-chose d'Astro. Cependant, si vous souhaitez envoyer moins de poids JavaScript à vos utilisateurs tout en conservant le DX de quelque chose comme Next.js, alors Astro pourrait être fait pour vous.

Astro est destiné aux sites Web axés sur le contenu et fournit une prise en charge des démarques prête à l'emploi. En raison de son orientation vers le contenu, il s’agit d’une plateforme de blogs de développeurs idéale pour remplacer un site WordPress ou Hugo. Cependant, il est capable de bien plus que de simples sites de contenu grâce à des fonctionnalités telles que les actions.

Malgré mon fort dégoût pour le routage basé sur les fichiers, ma plus grande préoccupation concernant l'adoption d'Astro est le potentiel de changements cassants qui m'obligeraient à reconstruire mes sites. Les outils JavaScript sont beaucoup plus agressifs en matière de modifications brutales que les outils que vous trouvez dans d'autres écosystèmes linguistiques. Parce que je suis si nouveau sur Astro, je ne sais pas à quel point les changements d'une version majeure à l'autre. Même avec ce souci, je prévois de déplacer 5 à 6 de mes sites d'autres plateformes vers Astro afin de pouvoir profiter de son DX de premier ordre et héberger les sites à moindre coût.

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!