Deno / Fresh 使う
Getting Started
- Create a project
- Running locally
- Create a route
- Dynamic routes
- Custom handlers
- Form submissions
- Adding interactivity
- Deploy to production
Concepts
用語
- ルート route
- プロジェクトの特定のパスへのリクエストを処理するロジックをカプセル化する
- API リクエスト、HTML ページのレンダリングに使用する
- ファイルシステムルーティング
- ルートが処理するパスをディレクトリ構造(ファイルシステム)によって決定するルーティング方法
- Fresh では、
routes
ディレクトリの構造を下に、リクエストを処理するロジックへの振り分けが行われる
アイランドアーキテクチャ:Fresh へのインタラクティビティの追加
Fresh では、ウェブページにインタラクティビティを追加するために、アイランドアーキテクチャを採用している。
現世代の多くのウェブフレームワークでは、クライアントにJavaScriptを全く送信しないか、ページ全体のレンダラーを送信するかの選択肢があります。
これはあまり柔軟ではありません。特に、ほとんどのページでインタラクティビティを必要とするのは小さな部分だけであることを考えると、そうです。例えば、それ以外は静的なページでも、画像カルーセルや「今すぐ購入」ボタンを動かすために少しのJavaScriptが必要かもしれません。このモデルはしばしば「アイランドアーキテクチャ」と呼ばれます。これは、それ以外は静的なコンテンツの海の中に、小さな「インタラクティビティの島」があるページを指します。
Freshはこのモデルを採用しています。全てのページはサーバーサイドでレンダリングされますが、クライアントサイドでもレンダリングされる「アイランドコンポーネント」を作成できます。
ハイドレーションとは
ハイドレーション(Hydration)は、フロントエンド開発、特にサーバーサイドレンダリング(SSR)を使用するモダンなJavaScriptフレームワークにおいて重要な概念です。以下にハイドレーションの概要を説明します:
-
基本的な定義:
ハイドレーションとは、サーバーでレンダリングされたHTMLコンテンツに、クライアントサイドのJavaScriptを「注入」してインタラクティブにする過程を指します。 -
プロセス:
- まず、サーバーがHTMLを生成し、クライアントに送信します。
- クライアント(ブラウザ)がこのHTMLを受け取り、表示します。
- その後、JavaScriptがロードされ、既存のHTML構造に「ハイドレート」(水分を与える、活性化する)します。
-
目的:
- 初期表示を高速化(サーバーレンダリングのおかげで)
- ページを完全にインタラクティブにする
- クライアントサイドのステート管理やイベントハンドリングを有効にする
-
メリット:
- 高速な初期ページロード
- SEOの改善(サーバーレンダリングされたコンテンツのおかげで)
- ユーザー体験の向上(早く見えて、すぐに操作可能)
-
具体例:
Reactの場合、ReactDOM.hydrate()
メソッドを使用します:ReactDOM.hydrate(<App />, document.getElementById('root'));
このコードは、サーバーでレンダリングされた既存のDOMにReactのイベントリスナーとステート管理を追加します。
-
注意点:
- ハイドレーションは追加のJavaScript実行を必要とするため、適切に管理しないとパフォーマンスに影響を与える可能性があります。
- サーバーとクライアントで同じ内容をレンダリングする必要があり、不一致があるとエラーが発生する可能性があります。
ハイドレーションは、モダンなウェブアプリケーションにおいて、サーバーサイドレンダリングの利点(高速な初期ロード、SEO)とクライアントサイドレンダリングの利点(リッチなインタラクション)を組み合わせるための重要な技術です。
なぜアイランドアーキテクチャが重要か?
典型的なシングルページアプリケーション(Single Page Application、SPA)アーキテクチャと比較すると、多くの利点がある。
プログレッシブハイドレーション
私は以前から、React、Angular、Preact、Vueなどのフレームワークで使われているプログレッシブハイドレーション技術のパフォーマンス上の利点を主張してきました。これらのアーキテクチャでは、ページ上の個々のウィジェットが時間をかけてロードされ、初期化されます。これは、requestIdleCallbackを使用した単純なスケジューリングアプローチで実現できます。さらに、ビューポートの可視性、インタラクションの可能性、製品の価値など、追加の要素を考慮に入れることもできます。
あまり理解できてない。単純なスケジューリングアプローチで実現できるのはよいこと?
プログレッシブハイドレーションと同様に、アイランドアーキテクチャを使用してページをレンダリングすると、ページの動的な部分が段階的に、そして個別に初期化されます。つまり、ページの他の部分がまずロードされる必要なく、個々の領域が対話可能になるのです。
プログレッシブハイドレーションとは異なり、アイランドアーキテクチャを中心に構築されたアプローチではトップダウンのレンダリングが不要です。これは明確な利点です。なぜなら、子孫の前に初期化しなければならない外側の「ルート」コンポーネントがないからです。ページの各部分は独立したユニットであり、一つのユニットのパフォーマンス問題が他のユニットに影響を与えることはありません。
SPA だとルートコンポーネントから徐々に子コンポーネントがレンダリングされていく。上位コンポーネントのレンダリングが子コンポーネントのレンダリングに影響する。
これに対して、アイランドアーキテクチャは独立したコンポーネントが個々にレンダリングされ、パフォーマンス問題が特定しやすくなる?
ものすごくどうでもいいけど、海を静的なものの例えとしているのは考えが分かれそう(自分は海は動的派だけど、islands architecture では海は静的な HTML に例えられている)。
ここで述べた placeholders/slots にハイドレートされるコンポーネントこそ Islands であり、Islands Architecture とは、大海原に点在する島のように静的 HTML 内に動的な UI パーツを配置するという、ページ構成に関する設計方法を指します。次の画像は、上の記事内で Islands Architecture をビジュアルに説明するために提示されているもので、
- 全体が単一のページ
- 白背景の部分が静的な UI
- 背景が着色されている部分がインタラクティブな Islands
をそれぞれ表わしており、Islands Architecture のイメージをわかりやすく示しています。
Time To Interactive