私は最近、もともと WordPress、Go、Rails、Hugo で構築されたサイド プロジェクトを再構築するために Astro を使い始めました。私が Astro を選んだ理由は、優れた言語サーバー サポートを備えた React のような DX を備えていることと、豊富な無料枠があるサーバーレス ホスティング プラットフォーム (Cloudflare、AWS Lambda など) と互換性があるためです。
Astro を使い始めたとき、私は Astro についてあまり知りませんでした。複数のサイトを移行したので、フレームワークの使用を検討している他の人のために、フレームワークについて気に入った点と気に入らなかった点を共有したいと思いました。
Astro の核心は、必要に応じてサーバーでレンダリングされた動的なページを生成する機能を備えた静的サイト ジェネレーターです。 Astro は、インタラクティブ性が限られたブログや小規模なマーケティング サイトに最適です。このフレームワークは、React.js のオーバーヘッドなしで Next.js の DX のほとんどを提供します。
正直に言うと、従来のサーバーでレンダリングされるテンプレート言語には、優れた言語サーバーのサポートとコードの書式設定が大幅に欠けています。 Go テンプレート、Jinja、ERB、および EJS は、React/Vue/Svelte の対応するものと比較すると、ツールの点で痛ましいほど遅れています。サーバーでレンダリングされるテンプレート言語のほとんどは、どの変数がスコープ内にあるか、またはその型が何であるかを知る方法がありません。
Astro を使用すると、これらすべての機能を 1 つの VS Code 拡張機能で実現できます。
Astro テンプレート内では、ビルド時またはサーバー上のリクエストに応答するときに実行される「コード フェンス」内のテンプレートの先頭にデータを設定します。実際の動作は次のとおりです:
---
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>
テンプレートのすべてのデータはテンプレートの上の「コード フェンス」にロードされるため、言語サーバーはスコープ内で定義されたオブジェクトのプロパティのオートコンプリートを提供できます。また、存在しない変数を使用しようとしている場合も示されます。
Go テンプレート、Jinja、EJS などの従来のテンプレート言語に対する私の最大の不満の 1 つは、子を受け入れることができる「コンポーネント」がないことです。私の Web サイトのほとんどには、幅が制限された何らかの「コンテナ」 UI 要素があり、ウルトラワイド モニターでコンテンツが画面の端に飛び出ないようになっています。
に手動で追加する .container クラスがある場合は、要素がある場合、これは通常は正常に機能します。ただし、Tailwind のようなユーティリティ CSS フレームワークを使用している場合は、すべての単一ページ テンプレートに次のコードを追加することになるかもしれません:<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>
Astro ファイルは 1 つのスロットに限定されず、複数のスロットを持つことができます。
Astro コンポーネントの私のお気に入りの機能は、コード フェンス内で props を受け入れることができることです。以下に例を示します:
---
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>
コンポーネントは、別のファイル内で使用されるときに props を受け入れることができます。
<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>
私は以前、Vite との独自のサーバー側統合を構築したことがあります。何かをオンラインですぐに入手したい場合、これは自分で構築することは避けたい種類の商品機能です。 Astro にはそれが組み込まれています。
Astro ページまたはコンポーネントにカスタム スクリプトを追加する場合は、ページにスクリプト タグをドロップするだけです。
---
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>
Astro は、サイトの構築プロセスの一部として TS および JS ファイルを自動的にコンパイルします。また、Astro コンポーネント内の script タグ内で、node_modules からのインポートを使用するスクリプトを作成することもできます。Astro は、ビルド時にそれをコンパイルし、独自のファイルに抽出します。
--- 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>
コード フェンス内に CSS または Scss スタイルをインポートすることで、Astro ファイルに CSS または Scss スタイルを含めることができます。
<div> <h1>This is my page</h1> <script src="../assets/script.ts"></script> </div>
Astro では、Astro ファイル内のスタイル タグを使用して スコープ スタイル を実行する機能も提供します。この機能は Vue ユーザーには馴染みのあるものかもしれません。
次の Astro ファイルがあるとします:
<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>
簡単ですよね?
アクションは、バックエンド関数を実行するタイプセーフな方法を提供します。これらは検証を提供し、JSON データとフォーム データの両方を処理できます。これらは明らかに Astro のキラー機能の 1 つです。これらすべてをオーダーメイドの方法で Next.js アプリに手動で接続する必要があります。サンプルにきれいに収まるよりも少し多くのコードが必要ですが、非常にエレガントに使用できます。アクション ドキュメント ページを読むことをお勧めします。
React は「十分速い」と言っている Twitter 開発者は数え切れないほどいます。多くの場合、そうではありません。
私は小さなプロジェクトに Rasbperry Pi 4s を使用していますが、React のランタイムコストを実感できます。安価な Android スマートフォンでも同じだと思いますが、その場合は JS のオーバーヘッドによってバッテリーも消耗します。
私のサイトに必要な対話機能がナビゲーション メニューの切り替えだけである場合は、それを自分で接続したいと思います。必要なときは喜んで React に手を伸ばしますが、非常に多くのプロジェクトでは実際には必要ありません。
Astro について私が嫌いな点は、このフレームワークに固有のものではありません。それらは、JavaScript エコシステムの他のツールから借用したアイデアです。
Astro はファイルベースのルーティングを採用しているため、Astro プロジェクト内のファイルの半分は、index.(astro|js|ts) または [id].(astro|js|ts) という名前になります。ファイルベースのルーティングは、Next.js が実装してからフロントエンドの世界を席巻した不快なパターンであり、多くの欠点があります。
認めます。10 ページ未満のサイトを作成する場合、ファイルベースのルーティングは非常に快適です。しかし、サイトが成長するにつれて摩擦が増大し、その機能から得られるメリットよりも、その機能と戦うことになります。
JavaScript エコシステムの中で、Remix は、すべてのルートを 1 つのディレクトリにフラット化するファイルベースのルーティングのバージョンを提供することで際立っており、ユーザーは手動のルート構成でファイルベースのルーティングを完全にオプトアウトできます。
ファイルベースのルーティングは、Astro に対する私の最大の不満ですが、それから逃れるのは難しい機能です。 Next.js、Nuxt.js、SvelteKit などで実装されています。さらに奇妙なのは、これらのフレームワークがアプリケーションの他の部分のファイル名についてほとんど意見を持たないことです。 Ruby on Rails とは対照的に、ほとんどの JavaScript フレームワークでは、ルーティングを除いて、 を除いて、ファイル名とプロジェクト構造に大きな自由度が与えられます。これは特殊なケースであり、特殊なケースによりソフトウェアが複雑になります。
私がとても気に入っている JavaScript 言語の機能は、単一のファイルで複数の変数、関数、クラスを定義できることです。これにより、言語レベルの制約のために途中で他のファイルに抽出する必要がなく、関連する機能を同じ場所に簡単に配置できるようになります。
Vue の単一ファイル コンポーネントと同様に、Astro ファイルではファイルごとに 1 つのコンポーネントを定義できます。私にとってこれは面倒に思えますが、Astro が回避策を提供します。
Astro は、クライアント側 JavaScript をロードせずに、事前レンダリングされた React、Vue、Svelte、Solid、および Preact コンポーネントをテンプレートに直接埋め込むことができます。 Preact JSX は React JSX よりも HTML にはるかに近いため、Preact コンポーネントは Astro と適度に うまく組み合わされます。ただし、Astro コンポーネントと Preact コンポーネントの両方を同じプロジェクトで管理するのは面倒で、Preact コンポーネントを使い始めると、ほとんどの UI を Astro ファイルから Preact に移動していることに気づきました。
もしあなたが Next.js、Nuxt、または SvelteKit の熱心なユーザーで、自分のフレームワークに満足しているのであれば、Astro からはあまり得られないかもしれません。ただし、Next.js などの DX を維持しながら、JavaScript の肥大化を減らしてユーザーに提供したい場合は、Astro が最適かもしれません。
Astro はコンテンツ主導型の Web サイトを対象としており、すぐに使えるマークダウンのサポートを提供します。コンテンツに重点を置いているため、WordPress や Hugo サイトに代わる理想的な開発者ブログ プラットフォームです。ただし、アクションなどの機能を使用すると、単なるコンテンツ サイト以上のことが可能になります。
私はファイルベースのルーティングに強い嫌悪感を持っていますが、Astro を採用する際の最大の懸念は、サイトの再構築を余儀なくされる破壊的変更が発生する可能性です。 JavaScript ツールは、他の言語エコシステムにあるツールよりも破壊的変更に対してはるかに積極的です。私は Astro を初めて使用するため、あるメジャー バージョンから次のメジャー バージョンにどれだけ変更があるのかわかりません。この懸念はありますが、私は自分のサイトの 5 ～ 6 つを他のプラットフォームから Astro に移行して、一流の DX を活用して安価にサイトをホストできるようにするつもりです。
以上がAstroの第一印象：好きなところと嫌いなところの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
