コンテナ

すべての Qwik アプリケーションは、通常は<html>要素である要素内に含まれています。この要素はアプリケーションのコンテナになります。コンテナはアプリケーションのルート要素であり、すべてのコンポーネント、状態、イベントはコンテナ内に含まれています。

<html q:container="paused" q:version="0.12.1" q:base="/build">
  ...
</html>

コンテナ属性

コンテナは Qwik ランタイムによって暗黙的にレンダリングされるため、JSX を使用してカスタム HTML 属性を定義することはできません。ただし、renderToStringやrenderToStreamなどの SSR レンダリング API は、カスタム属性を定義するためのcontainerAttributesオプションを提供します。

renderToStream(<Root />, {
  containerAttributes: {
    lang: 'en',
  },
});

上記のコードは次の HTML をレンダリングします。

<html lang="en" q:container="paused" q:version="0.12.1" q:base="/build">
  ...
</html>

上記の例では、lang属性が<html>コンテナ要素に追加されています。

この属性はリアクティブではないことに注意してください。アプリがこの値を動的に変更する必要がある場合、手動による DOM 操作を行う必要があります。

カスタム属性に加えて、Qwik はq:container、q:version、q:render、q:base属性を自動的にレンダリングします。

q:container - コンテナの状態。この属性は、Qwik ランタイムがコンテナが一時停止状態にあるかどうかの判断に使用されます。この属性の値はpausedまたはresumedのいずれかです。
q:version - Qwik ランタイムのバージョン。
q:render - コンテナがどのようにレンダリングされたかを示します。この属性の値はssr、ssr-dev、dom、dom-devのいずれかです。

プロパティ

ランタイムはコンテナ間での分離を確保するため、複数のコンテナが同じドキュメント内に共存できます。コンテナはさらにネストされた別のコンテナを含むこともできます。このプロパティにより、コンテナはアプリケーションをより小さな部分に分割できます。

**resumed**: 各コンテナは、ページ上の他のすべてのコンポーネントから独立して再開できます。独立した再開により、再開時に逆シリアル化される状態の量がさらに削減されます。
**updated**: 各コンテナは、innerHTMLを使用していつでも更新/置換できます。これにより、JavaScript をダウンロードまたは実行せずに、完全な HTML ドキュメントの完全な再フェッチを強制することなく、ページの一部を更新できます。
**compiled**: 各コンテナは、他のコンテナから個別にコンパイルおよびデプロイできます。個別のコンパイルは、大規模なアプリケーションと、アプリケーションに取り組んでいる大規模なチームにとって特に役立ちます。
**versioned**: 各コンテナは、異なるバージョンの Qwik フレームワークを実行できます。多くの小さなコンテナからウェブサイトの構成を可能にします。

コンテナはツリー状にネストでき、データの通信と共有が可能です。コンポーネント間の通信には、コンポーネントが明確に定義された境界を持つ必要があります。これをコンテナプロトコルと呼びます。

<html q:container="paused" q:version="0.12.1" q:base="/build">
  <head>
    <title>My Qwik Application</title>
  </head>
  <body>
    <header q:container="resumed" q:version="0.11.1" q:base="https://server.a/build">
      <div>
        <h1>This is a header form a container</h1>
      </div>
    </header>
 
    <footer q:container="paused" q:version="0.13.0" q:base="https://footer.server.b/">
      <div>
        <h1>This is a footer</h1>
      </div>
    </footer>
  </body>
</html>

コンテナとコンポーネント

コンテナはコンポーネントと非常に似ていますが、違いは何ですか？コンテナをより制限されたコンポーネントと考えてください。ただし、コンポーネントには、コンテナではできないことがいくつかあります。

コンテナには、読み取り専用の属性しか渡すことができません。この制限は、コンテナの入力は SSR リクエストのためにシリアル化される必要があるためです。
コンテナはコンテンツプロジェクションを理解しません。
コンテナは、渡された状態を変更できません。

コンポーネントには制限があります。

コンポーネントはまとめてコンパイルする必要があり、その結果、同じバンドルアーティファクトと Qwik バージョンを共有します。
一時停止すると、コンテナ内のすべてのコンポーネントがまとめてシリアル化されます（そして、まとめて再開されます）。

コンテナは何を解決しますか？

コンテナを使用すると、複数の独立したQwikアプリケーションをページ上で実行し、ユーザーに対して単一のアプリケーションとして動作させることができます。最も一般的なユースケースは2つあります。

ルーティング
マイクロフロントエンドアーキテクチャ

ルーティング

典型的なサイトは、2つの論理的な部分で構成されています。

多くのページで一定に保たれる傾向があるナビゲーション。
ユーザーが移動したルートに基づいてページの変更部分であるアウトレット。

この2つの部分を、ナビゲーションコンテナとアウトレットコンテナの2つとしてモデル化できます。ユーザーが最初にルートに移動すると、サーバーはナビゲーションとアウトレットの両方のコンテナを含むHTMLで応答します。ユーザーが2番目のルートに移動すると、ナビゲーションを解決する方法は3つあります。

単純なアプローチは、完全なラウンドトリップを行い、完全に新しいページをダウンロードすることです。主な欠点は、アプリケーションがクライアント上のすべての状態を失うことです。
従来のアプローチは、それ以降のナビゲーションをJavaScriptで処理することです。現在のアウトレットコンポーネントを新しいアウトレットコンポーネントで置き換え、新しいコンポーネントをレンダリングします。欠点は、JavaScriptをダウンロードして実行する必要があることです。
Qwikのアプローチは、ナビゲーションとアウトレットを2つの異なるコンテナとして扱います。最初のナビゲーションは、完全なページ（両方のコンテナを含む）を表すHTMLをダウンロードします。後続のナビゲーションでは、アウトレットコンテナのHTMLのみを取得します。このアプローチは、両方の長所を兼ね備えています。ナビゲーションは高速（JavaScriptのダウンロードや実行なし）であり、アプリケーションは親コンテナに状態を保持します。

マイクロフロントエンド

アプリケーションが非常に大きくなると、それを単一のアプリケーションとして考えるのは非現実的になります。より良いメンタルモデルは、多くのアプリケーションが連携して、ユーザーに単一のアプリケーションであるという印象を与えることです。

大規模なアプリの場合、チームも大きくなります。大規模なチームは通常、異なる目標を持ち、その結果、異なるリリーススケジュールを持つことになります。

コンテナを使用すると、大規模なチームはアプリケーションを多くの小さな部分に分割し、各部分を個別のデプロイ、テスト、およびバージョンアップグレードスケジュールを持つユニットとして扱うことができます。

チームはアプリケーションをコンテナに分割し、コンテナ間のプロトコルを明確に定義します。プロトコルが満たされている限り、各チームは2つのコンテナを独立してデプロイできます。

貢献者

このドキュメントの改善に貢献してくれたすべての貢献者に感謝します！