フロントエンド契約: はじめに
Wippyのフロントエンドモジュールはデフォルトでポータブルです。モジュールは、ファサードが別の準拠PrimeVueテーマを提供し、プロジェクト固有のCSSが存在しない別のWippyプロジェクトにインポートされても、引き続き動作しなければなりません。
正しい経路を選ぶ
about:srcdociframe内でレンダリングされるアプリケーションにはview.pageを使用します。- ホストドキュメント内でレンダリングされるカスタム要素には、通常はシャドウルートを伴う
view.componentを使用します。 - UIがボタン、入力、フォームフィールド、メニュー、オーバーレイ、その他PrimeVue相当のコントロールをレンダリングする場合、必要なセマンティクスとアフォーダンスをPrimeVueが提供できない場合を除き、PrimeVueを使用します。
- コントロールを持たないChart.js可視化のような、コンテンツのみのコンポーネントはPrimeVueとTailwindを省略できます。
- カスタムコントロールが必要な場合は、ポータブルUI契約とカスタムコンポジットに従います。
PrimeVueは共有のコンポーネント語彙です。Wippy Tailwindプリセットはサポートされたビルド時の語彙です。コンパイル後もファサードのテーマ変更に応答し続けるのは、ランタイムに裏付けられていると文書化されたユーティリティのみです。
所有関係マップ
module source
-> build command
-> emitted artifact
-> registry owner
-> served URL
-> Web Host
-> page srcdoc iframe or component shadow root
-> AppConfig / router / theme delivery
ある段階から別の段階を推測しないでください。アセットの欠落をデバッグする前に、ソースパッケージ、ビルドターゲット、生成されたファイル、レジストリエントリ、ファイルシステムのマウント、配信URLを特定してください。
契約ページ
- プラットフォームトポロジー: ランタイム境界、ルーティング、CSSの配信、オーバーレイ、所有関係。
- ポータブルUI契約: 規範的なコンポーネントとスタイリングのルール。
- テーマの作成: ファサードの
custom_css、PrimeVueテーマCSS、モジュールのいずれに何が属するか。 - Tailwind契約: ランタイムに裏付けられたユーティリティとコンパイル済み定数の違い。
- トークンカタログ: 生成されたトークンリファレンスとその出所。
- デザインレイヤー: 自分の複数のモジュールが同じものを必要とし、テーマにそのコンポーネントが存在しない場合、それがどこに属するか。
- ページのレシピとWebコンポーネントのレシピ。
- ビルドと依存関係の契約。
- 設定と命名規則。
- 準拠ルール一覧。
譲れないチェック項目
- PrimeVueのプロパティ、コンポーネントAPI、CSS変数、Tailwindのセマンティックユーティリティを決して発明しないでください。選択したパッケージのソースと生成されたカタログで確認します。
--p-*トークン名を類推で組み立てないでください。- ポータブルモジュールからファサードの任意のクラスを要求しないでください。
- ブラウザのlocationからホストのルートコンテキストを推測しないでください。ページはAppConfigを通じてホストのコンテキストを受け取り、
@wippy-fe/routerを使用します。 - ブラウザで検証する前に、所有元となるパッケージそのものを配信出力へ再ビルドしてください。
- ナビゲーションと実質的な操作の後に、ブラウザのコンソールを確認してください。
プロジェクト固有のモジュールはポータブル契約の対象外です。それらは非対応のプロジェクト固有モジュールのページでのみ扱われます。標準の準拠チェックはUNSUPPORTEDを返し、標準のCIは失敗します。